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new for network designers 


Now, your computer and communications 
network analysis simplified 


NETWORK 11.5 gives you results quickly—no programming 



quick reliable answers to your network performance questions 


free trial -see how NETWORK II. 5 measures the ability 
of a proposed network to perform under various workloads 


no programming 

ou get your results quickly-no 
programming. You simply 
enter your system description 
through the interactive, user-friendly 
interface. 

Your description is automatically 
verified—corrections are made im¬ 
mediately. 

your system simulated 

You can analyze any computer 
and communications system, large 
or small, including local area net¬ 
works. You get measures of hard¬ 
ware utilization, software execution, 
response times, queue sizes and con¬ 
flicts. 

You can simulate some portions 
of the system at a detailed level and 
others at a coarser level. 

results 

Your reports show utilization, 
queues, execution times and 
response times. Graphical reports 
show hardware layout, software 
data flow, and device utilization as a 
function of time. 


free trial 

Solve your own network problem 
on your own computer—no cost or 
obligation. 

We will send you everything 
needed for a free trial: the NET¬ 
WORK II.5® system, installation in¬ 
structions, a sample network, and 
complete documentation. 

If you have questions call us for 
immediate help. 

computers with NETWORK II.5 

1. IBM Personal Computer AT- 
XT or compatible. 

2. Most Mainframe computer 
types including IBM, CDC, VAX, 
Univac, Prime, Gould, and Data 
General. 

special offer-free training 

For a limited time we will also give 
you a free enrollment in our popular 
network analysis course-an $850 
value. 

You must act now; class size is 
limited and they fill up quickly. 

Call Paul Gorman now at 
(619) 457-9681 for more information 
or to reserve your free course 
enrollment-no obligation. 


rush information on free trial 

free trial-learn the reasons for the 
| broad and growing popularity of 
NETWORK II.5. Try NETWORK 
I II.5, user instructions, training, 
documentation, and user sup- 
I port—no cost or obligation. 

! special offer- return the coupon 
| today and we will include a free 
course enrollment worth $850. 



return to: 


CACI 

3344 North Torrey Pines Court 
La Jolla, California 92037 

Or better yet, 

call Paul Gorman at (619) 457-9681 


NETWORK 11.5 is a registered trademark and service mark of 
CACI, INC.-FEDERAL 

© 1986 CACI, INC.-FEDERAL 
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DIRECTOR - CITI 

The Center for Information Technology Integration (CITI), is a new organization at 
— e University of Michigan. The Director is one of the key positions reporting to 

! Vice Provost of Information Technology. 

n was established to provide a major research and development arm for the 
University’s Information Technology Division (ITD), and to provide the critical link 
with industry that will enable the University to build the most advanced information 
technology environment in higher education. The envisioned multi-vendor environ¬ 
ment will be based upon a network of thousands of high performance individual 
workstations, several mainframe computers and widely distributed servers with a 
variety of capabilities. 

The Director of CITI provides supervision and leadership for a staff that is expected 
to grow to about 40 professional employees. The Director also manages a growing 
annual budget, expected to exceed $2 million. Other major responsibilities include: 
identify, contact and develop potential industrial supporters, provide overall 
technical direction for the cooperative ventures with industry, and work closely with 
other members of ITD senior management and with various academic deans to 
strategically plan and develop the desired information technology environment. 

The successful candidate will be a leader who is articulate and highly effective in 
both written and oral communication with the academic, research and 
administrative components of the campus and who possesses creativity and vision 
for the future of information technology within higher education. Requirements 
include: a strong technical background, a strategic orientation, demonstrated large- 
scale system integration skills, an understanding of networking in heterogeneous 
computer environments, and a proven record in establishing and managing 
research and development activities. A Ph.D. in computer science or engineering 
and the qualifications for a tenured position are highly desirable. 

Send applications, including resume, by October 15, 1986 to: Virginia E. 

Rezmlerski, Ph.D., Assistant to the Vice Provost for Information Technology, 5077 
Fleming Administrative Bldg., Ann Arbor, Michigan 48109. 

The University of Michigan 


~The University of Michigan is 


minatory, affirmative action employer. 
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■ A complete, 96-page catalog for more 
than 2000 products—many available 
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descriptions; four-color photos of prod¬ 
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CAD/CAM printer and plotter supp 
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cable guide. 

■ Same-day shipping, 45-day trial, 
minimum 1-year guarantee, 10- 
year history of satisfied customers! 
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1 - 800 - 547-5444 
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Or complete and return the 
coupon below. 
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At GTE Government Systems, 
Our People Can Afford to be 

Entrepreneurs. 


GTE Government Systems takes you 
beyond the entrepreneurial spirit. We 
back up your initiative and enthusiasm 
with the resources of one of America's 
largest corporations. Consequently our 
people not only feel free to strive for 
innovative solutions, they also have the 
opportunity to see their ideas at work in 
the real world. 

Put your talents to work at any one of 
the many diverse GTE Government 
Systems areas of specialization. Accept 
the challenges presented by artificial 
intelligence, signal processing, vpice 
technology, lasers, and VLSI. Work on 
key defense programs employing Ada 
and other new languages. Participate in 
design and engineering projects which 
cross the borders of the impossible. 
Innovation, initiative, and independence 
are rewarded with full GTE support. 
Reach your potential working with the 
best equipment, the latest methodolo¬ 
gies, and the most talented profession¬ 
als in your field. We provide the tools, 
the room, and the environment... the 
rest is up to you. 

Some of the current career opportuni¬ 
ties at GTE Government Systems 
include: 

SYSTEMS ENGINEERING 

We are seeking Systems Engineers and 
Technical Managers for: 

• High-speed digital communication 
systems, TDMA/TDM/PCM 

• Spread spectrum communication 
systems 

• Mission planning and control 
systems 

• EW/ESM/ECM systems 

• Al/Expert systems 

• Direction-finding subsystems 

• Receiving and Processing 
subsystems 

• Real-time processing 

• Signal analysis 

• RF tracking systems 

• Over-the-horizon radar 
DIGITAL HARDWARE ENGINEERING 

• VHSIC/VLSI design 

• Digital design 

• Digital signal processing 

• Microprocessor hardware/software 

• Communications signal processing 
RF HARDWARE ENGINEERING 

• State-of-the-art microwave compo¬ 
nent design 

• High power component design for RF 
transmitter 



• Leadership opportunities targeting 
technology developments 

• System applications requiring crea¬ 
tive hardware design contributions 

MECHANICAL ENGINEERING 

• Electro-mechanical packaging and 
miniaturization 

• EMI/TEMPEST packaging 

• Thermal/structure design and 
analysis 

• Project Management 
MIL-SPEC experience required. 
SOFTWARE ENGINEERING 
Opportunities exist for skilled software 
engineers across a full range of 
defense system applications using 
development systems such as DEC/ 
VAX 8600 and MicroVAX II, PDP 11 
series, and the Hewlett-Packard 1000. 
Microprocessor applications are 
directed to Intel 8085/8086,Tl 32020, 
and Motorola 68000 processors. We 
are seeking senior people in the follow¬ 
ing areas: 

• ADA 

Use the DEC/VAX and MicroVAX II 
in our advanced development facility 
to build systems requiring: 
—Real-time analysis and control 


—Advanced MMI: multiple screen, 
color graphics 
—Relational DBMS 
—Networking on ETHERNET/VAX 
clusters 

—Large system development 
(300,000 lines of source code) 
—Microprocessor applications 
(Motorola 68020) 

• FIXED AND AIR-SEA-LAND 
MOBILE SYSTEMS 
Interdisciplinary software/firmware/ 
hardware teams build systems from 
high-level design through final test 
and integration using skills in: 
—Microprocessor applications 
—Real-time analysis and control 
—Test-bed development and 
analysis 

—Mapping and graphics displays 
-Man-machine interfacing 
—Concurrent processing 
—Software architecture design 
—Data base design and applications 
—Al/Expert systems 
THE BAY AREA 

The San Francisco Bay area is one of 
the world's most attractive locations. 
Here, geographic diversity is enhanced 
by fine climate, cultural richness and an 
abundance of recreational opportuni¬ 
ties. This energetic and dynamic envir¬ 
onment also provides a multitude of 
educational opportunities—many of 
America’s most outstanding universities 
are in close proximity. 

GTE Government Systems offers you a 
competitive compensation package, a 
professional work environment, and 
complete benefits which include 
educational assistance, a stock pur¬ 
chase plan, a tax-deferred savings 
plan, and much more. Please send your 
resume in complete confidence to: 

GTE Government Systems Corporation 

Western Division 

Dept. CC-329 

P.O. Box 7188 

100 Ferguson Drive 

Mountain View, CA 94039 


Government Systems 














With Digital's VAXstation II/GPX™ color workstation, Computer Aided 
Engineering and Computer Aided Software Engineering projects can now be 
tied into the computing resources of the entire company. 

VAXstation II/GPX’s built-in networking capabilities provide access to Digi¬ 
tal’s large VAX™ systems via Ethernet and DECnet™ networking software. And 
to other vendors’ systems via gateways and other communications protocols. 
By off-loading compute-intensive tasks to larger computers, the Micro VAX II™ 
CPU and GPX graphics coprocessor can concentrate on delivering exceptional 
graphics at tremendous speeds. Plus, you can monitor all aspects of a project 

VAXstation II/GPX: 

The end of isolation 
for CAE and CASE 
applications. 



on the screen’s multiple windows. 

VAXstation II/GPX runs popular CAE applications from such companies as 
Scientific Calculations, Inc., Silvar-Lisco,™ Tektronix™ - CAE Systems Division 
and VLSI Technology, Inc. It also runs CASE applications from B.S.O., Interactive 
Development Environments, Nastec Corp. and Tektronix - SDP Division. 

VAXstation II/GPX. The workstation comes out of isolation and into the 
mainstream. For brochures, write: Digital Equipment 
Corporation, Media Response Manager, 200 Baker Ave., 

West Concord, MA 01742. Or call your local sales office. 


© Digital Equipment Corporation 1986. Digital, the Digital logo, DECnet, MlcroVAX 11, VAX and VAXstation II/GPX: 
Silvar-Usco is a trademark of SUvar-Lisco. Tektronix is a trademark oflfcktronix, Inc. 




s trademarks of Digital Equipment Corporation. 






From the President 


TOTALCONTROL 

with LMI FORTH ™ 



For Programming Professionals: 

an expanding family of 
compatible, high-performance, 
Forth-83 Standard compilers 
for microcomputers 



For Development: 

Interactive Forth-83 Interpreter/Compilers 

• 16-bit and 32-bit implementations 

• Full screen editor and assembler 

• Uses standard operating system files 

• 400 page manual written in plain English 

» Options include software floating point, arithmetic 
coprocessor support, symbolic debugger native code 
compilers, and graphics support 

For Applications: Forth-83 Metacompiler 

• Unique table-driven multi-pass Forth compiler 

• Compiles compact ROMable or disk-based applications 

• Excellent error handling 

• Produces headerless code, compiles from intermediate 
states, and performs conditional compilation 

• Cross-compiles to 8080, Z-80, 8086, 68000, 6502, 8051, 
8096, 1802, and 6303 

• No license fee or royalty for compiled applications 

For Speed: CForth Application Compiler 

• Translates “high-level” Forth into in-line, optimized 
machine code 

• Can generate ROMable code 

Support Services for registered users: 

• Technical Assistance Hotline 

• Periodic newsletters and low-cost updates 

• Bulletin Board System 

Call or write for detailed product information 
and prices. Consulting and Educational Services 
available by special arrangement. 


Vote! 

This year, candidates for president, president-elect, first and 
second vice presidents, and the Board of Governors are being 
presented to the members in the annual election. These can¬ 
didates were chosen from a group of highly qualified, 
dedicated, and enthusiastic individuals who are committed and 
willing to work for the welfare of Computer Society members. 

The candidates’ viewpoints are set forth in position 
statements, which appear in this issue of Computer (pp. 

87-94). In an established organization such as ours, candidates 
may very well have similar views, making your choice a more 
difficult one. The natural tendency is to take no action since 
any candidate might do equally well. Extra effort is required to 
sort out and identify the candidates who share your goals most 
closely. We believe that this extra effort is worthwhile and will 
benefit both you and the Computer Society. 

Last year, the ballots were sent by third-class mail to reduce 
costs. Some of you may not have received the ballot, and some 
who did receive it may have mistakenly put it aside as unimpor¬ 
tant mail. Since the Board of Governors believes that the elec¬ 
tion is important enough to warrant the extra cost, ballots are 
being sent by first-class mail this year. 

When you receive your ballot, please take the time to read 
the candidates’ statements and make your decisions. Your vote 
supports the candidates of your choice and encourages all the 
winners to do their best. Please vote! 


urn 


Laboratory Microsystems Incorporated 

r Post Office Box 10430, Marina del Rey, CA 90295 
'phone credit card orders to: ( 213 ) 306-7412 


I., London, 01-248 0962 


se-Neustadt, 7651-1665 
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The IBM System 
Developer’s Library 

-fours for only $4.95 


The IBM System 
Developer ’s Library 

-yours for only $4.95 


Please accept my application for trial membership and 
send me The IBM System Developer’s Library (00745) 
billing me only $4.95, plus shipping and handling. I agree 
to purchase at least three additional Selections or Alter¬ 
nates over the next 12 months. Savings range up to 30% 
and occasionally even more. My membership is cancel- 
able any time after I buy these three additional books. A 
shipping and handling charge is added to all shipments. 


No-Risk Guar:. Ifl am not satisfied—for any reason 

—I may return the Library within 10 days. My member¬ 
ship will be canceled, and I will owe nothing. 


_ 


Attention: IBM SYSTEM USERS- 


g Name_ 

Name of Firm_ 

(If you want subscription sent to your office) 

Address_Apt_ 

City_ 


you to keep totally informed on all 
areas of the information sciences. 

fits 


Please accept my application for trial membership and 
send me The IBM System Developer’s Library (00745) 
billing me only $4.95, plus shipping and handling. I agree 
to purchase at least three additional Selections or Alter¬ 
nates over the next 12 months. Savings range up to 30% 
and occasionally even more. My membership is cancel- 
able any time after I buy these three additional books. A 
shipping and handling charge is added to all shipments. 
No-Risk Guarantee: Ifl am not satisfied—for any reason 
—I may return the Library within 10 days. My member¬ 
ship will be canceled, and I will owe nothing. 


Take the IBM 
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compatible, high-performance, 
Forth-83 Standard compilers 
for microcomputers 



PC/FORTH 







Vote! 

This year, candidates for president, president-elect, first and 
second vice presidents, and the Board of Governors are being 
presented to the members in the annual election. These can¬ 
didates were chosen from a group of highly qualified, 




For Development: 

Interactive Forth-83 Interpreter/Compilers 

• 16-bit and 32-bit implementations 

• Full screen editor and assembler 

• Uses standard operating system files 

• 400 page manual written in plain English 

® Options include software floating point, arithmetic 
















































































Attention: IBM SYSTEM USERS- 



Take the IBM 

System 

Developer’s 

Library 

for only $4.95 

when you join the 
Library o t Computer 
and Information 
Sciences. 

You simply agree to buy three 
more books—at handsome dis¬ 
counts—within the next 12 months. 

On-Line Systems Design and Imple¬ 
mentation Using COBOL and Com¬ 
mand Level CICS 

Charles J. Kacmar. This example-filled 
guide shows you how CICS is struc¬ 
tured and how transactions are initi¬ 
ated, controlled and terminated. It’s 
written from the viewpoint of a work¬ 
ing designer who needs to be able to 
quickly evaluate the impact of different 
design decisions upon an application. 
Publisher’s Price: $26.95. 


CICS: Mastering Command Level 
Coding Using COBOL 

William G. Bruno and Lois Bosland. 
Explains how transactions are initiated, 
the role of internal CICS tables and 
work areas, how to handle abend pro¬ 
cessing and exceptional conditions, 
how to format screens using BMS, how 
to handle files, reading and browsing, 
adding and deleting, file pointers, and 
much more. Publisher’s Price: $24.95. 


VSAM Concepts, Programming, 
and Design 

Jay Ranade and Hirday Ranade. A 
comprehensive reference guide to 
IBM’s widely-used Virtual Storage 
Access Method (VSAM). Covers 
VSAM/ICF catalog management and 
security, access method services com¬ 
mands, VSAM data set allocation, 
alternate index allocation, COBOL 
coding, processing KSDS with and 
without alternate indexes, processing 
ESDSs and RRDSs, and much more. 
350 pages. Publisher’s Price: $34.95. 


The Library of Computer and Infor¬ 
mation Sciences is the oldest and 
largest book club especially designed 
for the computer professional. In the 
incredibly fast-moving world of data 
processing, where up-to-date knowl¬ 
edge is essential, we make it easy for 


you to keep totally informed on all 
areas of the information sciences. 

Begin enjoying the club’s benefits 
today! 


4 Good Reasons to Join 


1. The Finest Books. Of the hundreds of books 


















MITRE 



The Right 
Time... 
Place... 
Projects 


Radar Systems 

Digital Signal Processing • Radar Sys¬ 
tem Surveillance Techniques* Radar 
System Analyses • Anti Jam Analyses 

• Intelligence Operations Analyses 

• Embedded Computer Hardware and 
Software 

System Software 

On VM • CMS • VCNA • RSCS • VS1 

• RSTS • RSX 11-M • UNIX • VAX/ 
VMS • Design, Implement and Docu¬ 
ment System Software • Performance 
Monitoring • Software and Hardware 
Evaluations • Enhance User Facilities 

• Applications Software—Corporate, 
Financial & Administrative Applica¬ 
tions; MVS/COMPLETE/ADABAS 
Environment; PL/1 & NATURAL Pro¬ 
gramming Languages 

Software Technology 

Knowledge Based Expert Systems 

• Automatic Programming ‘Fault Tol¬ 
erant Systems • Reusable Software 

Software Engineering 

Prototype Development • Performance 
Simulation • Ada Compiler Evaluation 

• Software Cost Estimation • Project 
Management Tools • Artifcial Intelli¬ 
gence 

Civil Programs 
McLean, VA Only 

Computer Systems Architecture & En¬ 
gineering • Systems Acquisition Man¬ 
agement • Systems Planning & 
Analysis • Requirements Analysis & 
Definition* Computer Technology 

• Real-Time Computer Software Analy¬ 
sis & Sizing • Display Technology 

• Bus-Oriented System Architectures 

• Local Network Design • Radar Sys¬ 
tem Design 


Communications 

System Design and Analyses • Digital 
Communications • Microprocessor Ap¬ 
plications • Communications Proces¬ 
sors (Hardware and Software) • Local 
Area Network • Protocol Development/ 
Evaluation • Modulation/Coding Tech¬ 
niques • Secure Communications 

• Systems Test and Evaluation 

• Switching and Control Systems 

• Satellite and Terrestrial Transmission 

• Survivability/Vulnerability and Elec¬ 
tromagnetic Pulse • Line of Sight, 
Tropo, Millimeter Wave and Fiber- 
Optics 

Command And Control 

Air Defense Systems (Deployable and 
Fixed) • Tactical Air Traffic Control Sys¬ 
tems (Deployable and Fixed) • Foreign 
Air Command and Control • Missile 
Warning Systems • Satellite Surveil¬ 
lance Systems • Systems Analyses 
and Specifications • Software 
Development 

Computer Systems 

Requirements Analyses • Systems 
Analyses • Technology Assessment 

• System Acquisition • Performance 
Analyses • Simulation and Analytical 
Modeling • Artificial Intelligence • Im¬ 
age Processing • Fault Tolerant Sys¬ 
tems • Ada • Software Cost Estimation 

• Computer Security • Software Met¬ 
rics • Distributed Data Base Systems 

• Program Verification 

Systems Architecture 

Advanced Systems Design • Ad¬ 
vanced Planning • Intersystems Engi¬ 
neering • Functional/Operational 
Analyses • Systems Inter-Operability 

• Cost Analyses 

U.S. CITIZENSHIP REQUIRED. 


Cl 

System 

Engineering 


MITRE's System Engineers know their projects are truly 
important, extremely timely, and in an environment 
where they can depend on superb support. Because our 
primary mission is system engineering of crucial Com¬ 
mand, Control and Intelligence (C 3 I) projects for the 
U.S. and the Free World. 

At MITRE's suburban Boston and Washington D.C. facil¬ 
ities, we're engaged in major defense projects including 
jamproof voice communications, airborne warning and 
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Peak vs. Sustained 
Performance in Highly 
Concurrent Vector 
Machines 


James J. Hack 

National Center for Atmospheric Research 


Is the peak 
performance of 
supercomputers a 
realistic measure of 
their processing 
capabilities? 


R ecent announcements of the NEC 
SX-2 vector processor, the Cray Re¬ 
search CRAY-2 vector multiproces¬ 
sor, and the ETA-10 vector multiprocessor 
have undoubtedly attracted much atten¬ 
tion considering their respective peak 
computational rates of 1300, 1950, and 
9600 Mflops (Millions of FLoating point 
Operations Per Second). These announce¬ 
ments have followed several other scientif¬ 
ic computer announcements, each of 
which has emphasized the peak computa¬ 
tional rate of the machine, neglecting the 
more important sustained performance 
estimates. 

Sustained computational performance 
for a vector machine is considerably more 
difficult to determine since it will vary with 
the level of vectorization one can achieve. 
By level of vectorization I mean the 
percentage of the total useful work to be 
completed by a program (which is as¬ 
sumed to be approximately proportional 
to the time required to do that work on a 
scalar machine) that can be accomplished 
using vector operations. In other words, 
the fraction of the total scalar instruction 
workload that can be shifted to the vector 
unit. Since the ability to translate a prob¬ 
lem into operations involving aggregates 
of data (vectors) is a measure of low-level 
parallelism, the degree of vectorization 
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one can hope to achieve is determined to 
first order by the scientific/engineering 
application area. Some applications readi¬ 
ly exhibit such parallelism while others do 
not. Because this type of machine architec¬ 
ture can offer a significant performance 
improvement, much research in the area 
of algorithm development, aimed at in¬ 
creasing the level of vectorization and ease 
of memory management, is under way. 1,2 
Efficient implementation of these algo¬ 
rithms by high-level language compilers, 
that is, taking full advantage of the 
concurrency available in the hardware 
through judicious instruction scheduling, 
is also essential to achieving optimal com¬ 
putational performance. 

Simple knowledge of the level of vector¬ 
ization is not sufficient by itself to deter¬ 
mine the overall sustained performance, 
though, since factors such as the average 
vector length (amortization of the vector 
startup penalty), the ability to chain and 
overlap vector operations (concurrent 
utilization of various independent func¬ 
tional units), and memory access patterns 
(memory contention) will have a signifi¬ 
cant impact on the average vector unit per¬ 
formance, which in turn affects the net 
sustained processor performance. It is not 
only important to identify those factors 
that contribute to the average internal per¬ 
formance of the processor, but it is essen¬ 
tial to consider other factors that can 
meaningfully degrade turnaround, an¬ 
other way of evaluating sustained (system) 
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performance. As one example, for those 
applications not entirely contained in 
main storage, I/O latencies and I/O 
transfer rates can severely degrade the net 
sustained performance (in terms of turn¬ 
around) because of low processor utiliza¬ 
tion, despite high internal processing 
speed. 

The exceptionally high peak rates 
claimed for the latest generation of vector 


machines are generally achieved by attach¬ 
ing multiple pipes to the vector unit, which 
are fed by very fast and large main memo¬ 
ries. By pipe I mean a minimum of one 
pipelined (segmented) floating point adder 
and one pipelined floating point multiplier 
that operate both cooperatively and/or 
concurrently. A machine with four pipes 
can theoretically produce up to eight float¬ 
ing point arithmetic operations per clock 


cycle, four times the peak rate of a one- 
pipe machine. Some of the new machines 
appear to achieve equivalent theoretical 
rates with fewer arithmetic pipes by cy¬ 
cling the vector hardware at twice the rate 
of the scalar hardware. Thus, the peak rates 
are determined by assuming that each 
floating point functional unit produces 
one result for each vector unit clock cycle. 
Unfortunately, computational rates calcu- 


(a) Sequential Machine Organization 
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Peak Rate = 1 FPO/cycle 

Sustained Loop Rate = 2N/(5N+3s+m + a) FPO/cycle 
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(b) Chain Arithmetic 
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Peak Rate = 2 FPO/cycle 

Sustained Loop Rate = 2N/(4N+3s+m+a) FPO/cycle 
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(c) Chain Load and Arithmetic 



Peak Rate = 2 FPO/cycle 

Sustained Loop Rate = 2N/(3N+3s+m + a) FPO/cycle 


memory path busy 


(d) Chain Load. Arithmetic and Store 
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memory path 1 busy 
memory path 2 busy 


Peak Rate = 2 FPO/cycle 

Sustained Loop Rate = 2N/(2N+3s+m+a) FPO/cycle 


(e) Overlap Load with Chained Operations 



memory path I busy 
memory path 2 busy 
memory path 3 busy 


Peak Rate = 2 FPO/cycle 

Sustained Loop Rate = 2N/(N + 2s+m+a) FPO/cycle 


Figure 1. Timing diagram illustrating the execution of the vector operation Y(1:N)= Y(1:N)+ A*X(1:N) for different vector machine 
organizations. 
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lated in this fashion bear little resemblance 
to the average vector computational rate 
(or what might be called a typical inner 
loop computational rate), and even less re¬ 
semblance to the sustained computational 
rate achieved on a complete job basis. 

It is not the purpose of this article to 
attempt to relate peak vector rate to a 
characteristic vector rate. This is generally 
difficult to establish, although recent 
investigations have attempted to define 
experimentally verifiable parametric mea¬ 
sures of performance that together pro¬ 
vide a better estimate of the vector unit 
capabilities (see, for example, Hockney 3 ). 
Typically, vector rates attained from high- 
level compiled source code have been 
found to be significantly lower than the 
machine peak rate. For example, 30 
Mflops is often cited as a good vector rate 
for Fortran code on the Cray-lS, substan¬ 
tially less than the 160 Mflops * peak rate. 4 
Creative Fortran coding techniques can 
help the compiler to generate code that cir¬ 
cumvents certain machine organization 
bottlenecks, achieving higher rates, al¬ 
though still much lower than the peak vec¬ 
tor rate. 5 

One can gain some insight into some of 
the more important machine organization 
constraints on average vector perfor¬ 
mance (inner loop performance) by ex¬ 
amining a basic but frequently used vector 
operation in linear algebra known as a 
SAXPY. This operation involves the mul¬ 
tiplication of a vector by a constant and 
the addition of the result to another vector. 
The following discussion refers to Figure 
1, in which the performance of this opera¬ 
tion on a register-based processor archi¬ 
tecture is considered. The five execution 
steps shown on this time diagram are load 
vector A", load vector Y, multiply vector A' 
by scalar A (assumed to already be 
loaded), add the result to vector Y, and 
store the updated vector Y. The latencies 
(or vector startup times) are denoted as s 
for storage references, m for multiplica¬ 
tion, and a for addition; the value AT repre¬ 
sents the number of elements (or vector 
length). 

The simplest vector machine organiza¬ 
tion would be purely sequential one, in 
which each vector instruction would be 
completed before the next instruction 
could be issued (see Figure la). The peak 
rate for the SAXPY operation is one float¬ 


*In reality, the peak rate for the Cray-lS is closer to 
147 Mflops when vector startup times are considered, 
although 160 Mflops is the more appropriate figure for 
direct comparison to the peak rates as they are most fre¬ 
quently cited. 


ing point operation per cycle for such a 
machine, but the sustained loop rate is 
2N/(5N + 3s + m + a) floating point op¬ 
erations per cycle. For large N (where Alin 
practice is limited by the depth of the vec¬ 
tor registers), the sustained rate at the loop 
level asymptotically approaches 40 percent 
of the peak rate. An even larger discrepan¬ 
cy is shown in Figure lb, where chaining of 
arithmetic operations is allowed. Al¬ 
though a peak rate of two floating point 
operations can be claimed, the sustained 
loop rate is less than one- fourth this value 
because of the constraints on chaining 
arithmetic operations with memory opera¬ 
tions. As these machine organization con¬ 
straints are relaxed to allow additional de¬ 
grees of chaining and instruction overlap, 
the sustained loop performance begins to 
approach the peak rate. Even in the best 
case, however, where instruction overlap 
and chaining are allowed, the sustained 
loop rate is still below the peak rate and 
depends quite strongly on the ratio of the 
sum of the startup times to the vector 
length N. Because of the importance of the 
startup times, multiple vector pipes do not 
necessarily provide a linear improvement 
in sustained loop performance. Also note 
that the last two cases in Figure 1 place the 
most severe demand on the memory sys¬ 
tem, since they require the delivery of 
more than one operand per machine cycle. 
This places an implicit requirement for a 
comparable physical address generation 
rate. Support of multiple vector pipes 
creates an even more severe demand on 
address generation as well as on the pack¬ 
aging and memory technology. 

Although this discussion ignores issues 
like vector register reuse, which can have a 
positive impact on the performance of the 
simpler machine organizations, it illus¬ 
trates the fundamental performance bot¬ 
tlenecks that make it very difficult for a 
vector processor to operate anywhere near 
its peak rate on an average basis. Certain¬ 
ly, the average vector rate will be lower 
than the peak vector rate, and it is the aver¬ 
age vector rate that is most significant 
when attempting to make a realistic esti¬ 
mate of the overall sustained computa¬ 
tional rate. 

With few exceptions, most of the new 
vector processors are designed to support 
multiple vector pipes. The philosophy of 
this machine organization appears to 
strongly emphasize the performance of the 
vector unit as a means of improving the 
sustained execution rate. An alternative, 
although not necessarily mutually exclu¬ 
sive approach, to achieving a better overall 


computational performance in a scientific 
processor might be to improve the scalar 
execution rate. In the absence of a unique 
approach to the problem of improving 
sustained performance, how does the 
computer designer decide on the most ap¬ 
propriate machine organization strategy? 
In this article, an attempt will be made to 
demonstrate that a reasonable balance be¬ 
tween vector and scalar performance must 
exist in order to achieve a relatively robust 
sustained internal computational rate. 

Although the issue of balancing the 
computational capabilities of vector or 
multiprocessing systems has been dis¬ 
cussed formally (and more often informal¬ 
ly) in the past, 6 ' 9 the recent infatuation 
with peak rate has led more than one ap¬ 
parently informed observer to highly ques¬ 
tionable conclusions regarding the capa¬ 
bilities of the latest generation of vector 
machines. 10 Consequently, in this article I 
present yet another simple analysis that I 
believe will clearly demonstrate that peak 
computational rates, even if they were in 
practice achievable, are a useless measure 
of sustained performance unless consid¬ 
ered with respect to the computational rate 
of the slower scalar processor. 

Methodology 

In this section a hypothetical machine 
that can perform work at a variety of com¬ 
putational rates is considered. For the pur¬ 
pose of the following discussion, it will not 
be necessary to concern ourselves with the 
details of the machine architecture or ma¬ 
chine organization. Let us first define 
some arbitrary measure of total useful 
work W, such that 



where W could be the total number of 
floating point operations, the total num¬ 
ber of instructions, etc., and w(a) is the 
distribution of this total work in some 
space a. The time T required to complete 
the total work is equal to JV/7, where 7 is 
the average rate at which the work is ac¬ 
complished. The quantity 7 lies some¬ 
where between the slowest work rate r s 
and the peak work rate r p . The indepen¬ 
dent variable iris defined in terms of these 
bounding rates such that 

r(a) = r s (\-a) + ar p 0<o<:\ (2.2) 

The average or sustained rate 7 can now be 
derived from knowledge of the distribu¬ 
tion of the total work w(o), 
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Figure 2. Curves of constant P in the {\,n) plane. 


that can complete work at a variety of 
rates, in units of the slowest work rate. 

Analysis 

General characteristics of the perfor¬ 
mance parameter. In discrete form, the 
relationship in equation (2.7) can be written 

01 ) 

where c, is the discrete analogue of equa¬ 
tion (2.4) and represents the fraction of the 
total work that is performed at rate r,. The 
obvious difficulty with equation (3.1) is 
that knowledge of the distribution of 
useful work with respect to computational 
rate cannot be accurately established in 
general, even for a particular application 
program. This does not necessarily mean 
that the relationship has no value, how¬ 
ever, since it may be possible to extract 
useful information for certain special 
(limiting) cases. The simplest (nontrivial) 
example to which one could apply equa¬ 
tion (3.1) would be a machine that per- 



Thus, T can then be expressed as 


T=w['^-do (2.5) 

J o r(o) 

The time required to complete work W 
if done at the slowest rate is simply given 
by 



A dimensionless performance parame¬ 
ter P can be defined by forming the ratio 
of T s to T such that 



The parameter P expresses the sustained 
computational performance, of a machine 


formed work at two distinct rates, a fast 
rate r p and a relatively slow rate r s . Con¬ 
ceptually, one can think of these computa¬ 
tional rates as the peak vector rate (or in a 
more realistic estimate of P, the average 
vector rate), and the average scalar rate for 
a hypothetical vector machine. Neglecting 
for now the issue of overlapping scalar and 
vector operations, such a situation would 
represent the optimum performance sce¬ 
nario for a vector machine since all work 
completed by the vector unit is assumed to 
occur at the peak rate. Consequently, the 
results of the following analysis represent 
an upper bound on the net internal pro¬ 
cessor performance in the absence of 
vector-scalar overlap. 

Let us define X to be the fraction of the 
total work that is performed at the fast 
rate. In terms of our hypothetical vector 
processor, X is the fraction of the total 
scalar workload that can be moved to the 
vector unit, or more simply the level of 
vectorization. Equation (3.1) can then be 
reduced to 

P=[l-X(l-^- 1 )] -1 (3.2) 

where 



Thus, the dimensionless performance 
parameter P becomes a simple function of 
the fraction of the total work that can be 
performed at the highest execution rate, 
and of /I, the ratio of the fastest to the 
slowest execution rate. Isolines of this pa¬ 
rameter in the (X,/t) plane are plotted in 
Figure 2. Note that for the vast majority of 
the diagram there is almost no sensitivity 
of Pto variations in the parameter /*. Only 
in regions of the diagram where ranges X 
from 0.9 to 1.0 is there the suggestion of a 
significant dependence on large values of 
this ratio. 

Fixing n at some value yields the 
familiar performance curve for a vector 
machine as a function of the level of vec¬ 
torization. The more interesting curves are 
those for which the parameter X is fixed 
and P is plotted as a function of n. Four 
such curves are shown in Figure 3 for X= 
0.70, 0.80, 0.90, and 0.95. These perfor¬ 
mance curves can equivalently be thought 
of as an upper bound on the relative sus¬ 
tained performance for vectorization 
levels of 70, 80, 90, and 95 percent as a 
function of the ratio of peak to scalar exe¬ 
cution rate for a vector machine. The 
diagrams clearly demonstrate that, even 
for extremely high vectorization levels. 
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very large ratios of peak to scalar perfor¬ 
mance really don’t buy much in terms of 
sustained computational performance. 
The light vertical lines in the figures are 
meant to suggest the incremental nature of 
the performance improvement one might 
realize by adding multiple pipes to a vector 
unit. Each vertical line represents a dou¬ 
bling of peak performance, and help con¬ 
fine attention to the more realistic portion 
of the diagram. For example, if one vector 
pipe provided a ratio of vector to scalar 
performance equal to 10, two pipes would 
at best provide a ratio of 20, and four pipes 
a ratio of 40 at best. 

Intuitively, one should recognize that 
for any given computational task that can 
be performed at two (or more) separate 
rates, the maximum performance benefit 
will be limited by that piece that requires 
the longest execution time. This concept, 
as applied to the limitations of parallelism, 
was first discussed by Amdahl 6 and has 
since become known as Amdahl’s law. 
Thus, in the case of infinitely fast vector 
performance, the sustained performance 
would be entirely determined by the scalar 
execution rate. Note how rapidly these 
performance curves approach this asymp¬ 
totic limit, particularly for vectorization 
levels below 90 percent. The heavy solid 
line in Figure 2 indicates the point at which 
the sustained performance curves reach 90 
percent of the asymptotic rate. It appears 
that the sustained performance is not only 
limited by the scalar performance, but is 
for the most part dominated by it. 
Remember that these estimates represent 
an upper bound on sustained perfor¬ 
mance, and that a more realistic evalua¬ 
tion using the average vector rate instead 
of the peak vector rate would yield even 
lower values of P. 

The effect of vector-scalar overlap. The 

relationship given by equation (3.2) can be 
further generalized to include the effect of 
overlapping work completed at the slow 
(scalar) rate with work performed at the 
fast (vector) rate. The major difficulty 
with including this additional level of con¬ 
currency involves the precise definition of 
an overlap parameter. The simple non- 
dimensional performance relationship in 
equation (3.2) shows that the scalar unit 
requires (1 -X) units of time to complete 
its work, while the vector unit requires \n 
units of time for its fraction of the total 
work. Since for most levels of vectoriza¬ 
tion, X, the scalar execution time will be 
larger than the vector execution time, let 
us define the overlap parameter to be some 



Figure 3. Performance parameter as a function of ^ for selected values of X. Light vertical 
lines are drawn for n= 10, 20, 40, 80, and 160. 



Figure 4. Performance parameter as a function of e for selected values of X. Solid line is 
drawn for n= 10; the dashed line for ii= 160. 


arbitrary fraction of the vector workload 
that will be executed concurrently with 
work performed by the scalar unit. Ob¬ 
viously, the maximum amount of vector 
work that can be overlapped will be pro¬ 
portional to the smaller of either the vector 
or the scalar execution time. 

Mathematically, equation (3.2) can be 
extended to include overlap defined this 
way so that 


P=[ 1-X(1—m- 1 ) —e'V 
[l — X(1 — /* — ‘(1 — c 


(3.4) 



(3.5) 


and e is the fraction of the total work per¬ 
formed at the fast (or vector) rate that can 
be executed concurrently with work com¬ 
pleted at the slower (scalar) rate. The con¬ 
straint on t ' ensures that no more than the 
maximum allowable vector work is exe¬ 
cuted in parallel with scalar work. 

The performance parameter Pis plotted 
in Figure 4 for selected values of X and n as 
a function of the overlap parameter e. 
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Figure 5. Performance parameter as a function of X for selected values of e. 


Note that, for larger values of X and rela¬ 
tively small values of n, the overlap of 
scalar and vector work can provide con¬ 
siderable increases in sustained perfor¬ 
mance, and the greatest increments occur 
where e is already large. The diagram also 
suggests a curious behavior of the sus¬ 
tained performance parameter P for X = 
0.95 and /t = 10. As the degree of overlap 
is increased, the sustained performance 
increases up to the point at which there is 
insufficient scalar work to hide work oc¬ 
curring in the vector unit. The interesting 
characteristic of the resulting sustained 
performance curve is that it exceeds the 
computational performance of the vector 
unit. This unexpected behavior can be 
observed more readily by plotting P as a 
function of X for fixed n, and selected 
values of the overlap parameter e (see 


Figure 5). There appears to be an optimum 
level of vectorization, which is dependent 
upon the degree of overlap, at which point 
the sustained performance can be several 
percent larger than the peak (or average) 
vector rate. The maximum performance 
anomaly occurs where the scalar and vec¬ 
tor execution times become equal to each 
other, giving the illusion of infinite vector 
speed. This effect of concurrent execution 
by the vector and scalar units becomes 
more apparent for smaller values of n (and 
correspondingly small values of X). 

One might consider the benefits of vec¬ 
tor-scalar overlap in one other way by re¬ 
drawing the performance curves of 
Figure 3 for several selected values of e. 
These are shown for two vectorization 
levels (80 and 90 percent) in Figure 6. It is 
obvious from these diagrams that the 


overlap of vector and scalar work can 
help push the sustained performance 
much closer to the asymptotic limit for 
smaller values of fi, particularly for lower 
levels of vectorization. 

Constraints on sustained performance. 

Finally, it is useful to illustrate the way in 
which sustained performance is con¬ 
strained by establishing a sustained perfor¬ 
mance requirement and examining the 
range of the above set of parameters that 
satisfy or exceed this requirement. The re¬ 
lationships in equations (3.4) and (3.5) 
yield surfaces of constant P in (X, e, n) 
space. These surfaces, as uninteresting as 
they appear to be, reveal a great deal about 
application program vectorization and 
overlap requirements. The constraints on 
these parameters are plotted in Figure 7 for 
values of P given by 5.00 and 10.00. The 
lines that are drawn are lines of constant P 
in the (X, e) plane for selected values of n, 
which is equivalent to looking at several 
slices through (X, e, n) space. 

The interpretation of the diagrams is 
straightforward, where the lines of con¬ 
stant P define the leftmost extent of a 
region that satisfies or exceeds the sus¬ 
tained performance requirement. For ex¬ 
ample, if a sustained performance im¬ 
provement of five was required, and the 
ratio of vector to scalar performance was 
10, the application program would be re¬ 
quired to satisfy the vectorization and 
overlap parameters given in the region to 
the right of the solid line labeled n = 10 in 
the diagram labeled P = 5.0. The remain¬ 
ing lines show how these requirements are 
relaxed as the relative performance of the 
vector unit is increased. These diagrams 
clearly demonstrate that in order for an 
application program to achieve large 
values of P, it must satisfy a very strict set 
of conditions on vectorization and vector- 
scalar overlap. It is quite apparent that in¬ 
creasing the perforance of the vector unit 
relaxes these requirements only slightly, 
meaning that the sustained performance is 
primarily dominated by the properties of 
the applicaion. This is not, and should not 
be, a surprising qualitative conclusion, al¬ 
though the quantitative constraints are in¬ 
deed quite revealing. 

Perspective on peak performance.This 

article has presented an argument that 
grossly relates the sustained performance 
of a vector processor to the peak (or aver¬ 
age) vector performance as a function of 
the fraction of the total scalar workload 
that can be shifted to the vector unit, and 
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Figure 6. Performance parameter as a function of m for selected values of e. Light vertical 
lines are drawn for n= 10, 20, 40, 80, and 160. 


the fraction of this work that can be exe¬ 
cuted concurrently with the remaining 
scalar work. The argument is quite simple; 
yet it clearly shows that the peak vector 
performance, which appears to be the ba¬ 
sis upon which vector processors are most 
often compared, is of little value in 
determining the net internal sustained per¬ 
formance. The extra hardware cost of 
multiple vector pipes appears to buy small 
improvements in sustained performance, 
except for a very limited range of vectori- 
zation (and overlap) levels, particularly if 
the ratio of the vector to scalar execution 
rate for one pipe is already very large. It is 
worth noting that, although many scien¬ 
tific application codes were first believed 
to have vectorization levels in the area of 
90 percent, most codes in practice ex¬ 
hibited vectorization levels in the range of 
50-75 percent. 11 Therefore, unless the 
latest generation of vector machines has 
managed proportionally to improve scalar 
performance, it is unlikely that the sus¬ 
tained performance characteristics of 
these machines will immediately be all that 
much different from existing vector pro¬ 
cessors for a large majority of scien¬ 
tific/engineering applications. 

The optimal vector-scalar balance relies 
very strongly on the vectorization and 
overlap properties of the application pro¬ 
grams that will be executed on these pro¬ 
cessors. Two approaches to improving the 
sustained performance of a vector pro¬ 
cessor (for which n = 20) are contrasted 
in Figure 8, where only the vectorization 
characteristics of the application work¬ 
load are considered. One approach en¬ 
hances the vector unit capabilities (p = 80) 
while the other enhances scalar capability 
0t=10). Note that in this example the 
machine with enhanced scalar capability 
outperforms the machine with enhanced 
vector capabilities for all vectorization lev¬ 
els below 93 percent. Thus, the more ap¬ 
propriate of the two approaches can be 
readily determined if the vectorization 
characteristics of the application work¬ 
load are understood. The effort required 
to achieve the highest possible vectoriza¬ 
tion levels, as well as the most efficient 
hardware utilization levels, will involve 
more than making mechanical transfor¬ 
mations of existing code, since much par¬ 
allelism will continue to be hidden by defi¬ 
ciencies in algorithms and inadequacies of 
the programming languages through 
which algorithms are implemented. A 
strong familiarity with the scientific/engi- 
neering application can supplement such 
automatic vectorizing and software 


restructuring tools in order to efficiently 
exploit a given implementation of a vector 
architecture. This type of application 
knowledge will also prove to be invaluable 
in selecting the proper balance of vector 
and scalar performance. 

The issue of overlapping vector and 
scalar work is much less well understood. 
The section on the effect of vector-scalar 
overlap demonstrated that this kind of 
concurrency has the potential to provide 
improvements in performance that are 
similar to performance gains associated 
with a faster vector unit. Therefore, if vec¬ 
tor-scalar overlap is feasible, knowledge 
of typical overlap levels would be of con¬ 
siderable importance to the optimal design 
of a vector processor. Multitasking, i.e., 
overlapping scalar work with scalar work 


on multiple CPUs, could provide another 
means of reducing the impact of the slower 
scalar work rate on the net sustained per¬ 
formance of a vector processor. This ap¬ 
proach also represents a way to improve 
the sustained performance of the system in 
a more balanced way if vector work can 
also be partitioned. Considering the po¬ 
tential performance gains, a better under¬ 
standing of application code partitioning 
should be pursued in order to determine 
the hardware and software requirements 
that would maximize this type of concur¬ 
rency. These requirements will likely also 
prove to be application-dependent, since 
one is now searching for parallelism at a 
higher level of granularity, once again em¬ 
phasizing the importance of state-of-the- 
art application expertise. 
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Figure 7. Curves of constant P for selected values of m- 



Figure 8. Performance curves for three hypothetical vector processors. 


F inally, it is important to realize 
that I/O has the potential to 
render all arguments about sus¬ 
tained internal performance irrelevant. 
Unless I/O latency and I/O data transfer 
rates are proportionally improved, pro¬ 
cessor utilizations may prove to be very 
low yielding sustained performance num¬ 
bers, in terms of single job turnaround, 
that are orders of magnitude lower than 
peak rate. It is clear that mechanical 
devices will not be able to continue to k,eep 
up with the ambitious processor perfor¬ 
mance improvements planned for the re¬ 
mainder of this decade. This means that 
large, intermediate, electronic I/O devices 
will play an even larger role in maintaining 
a reasonable balance between the CPU in¬ 
ternal performance and application I/O 
requirements. Software to manage this 
I/O hierarchy at both the application and 
system level will probably prove to be the 
most important challenge in maintaining 
such a balance so that the full potential of 
the central processor can be realized. 

As the science of computing matures 
and more complex system solutions to im¬ 
proving turnaround are explored, a 
greater knowledge of the many scientific 
application areas will be required. This 
knowledge will be useful in intelligently 
choosing a reasonable balance between 
vector and scalar capabilities and essential 
to establishing a balance between pro¬ 
cessor speeds, memory requirements, and 
I/O requirements that achieve optimal 
system performance. Only by combining 
expert application knowledge with knowl¬ 
edge of advanced, exploitable processor 
and system solutions will future success in 
the design of high performance scientific 
computer systems be assured. □ 
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A Proposed Standard 
Format for RSA 
Cryptosystems 


Can public-key 
cryptography 
succeed without 
industry-wide 
standards? Some feel 
it's time to get started 
on them. 


Philip Zimmermann 
Boulder Software Engineering 


P ublic-key cryptography has not yet 
been widely accepted for commer¬ 
cial applications. There are some 
commercially available public-key encryp¬ 
tion products in the personal computer in¬ 
dustry that have not sold particularly well. 
One reason for this is that public-key cryp¬ 
tography is not well known, so its value is 
not yet appreciated by the industry. This 
situation may improve with time. 

Another possible reason is that the most 
popular public-key encryption algorithm, 
the Rivest-Shamir-Adleman (RSA) algo¬ 
rithm, is relatively slow compared to 
single-key algorithms such as the NBS 
Data Encryption Standard, or DES. How¬ 
ever, one may use RSA to “bootstrap” 
into the DES. Also, the speed of RSA may 
improve soon when VLSI hardware imple¬ 
mentations of the RSA algorithm become 
available. 

Another reason for the lack of commer¬ 
cial acceptance of public-key cryptog¬ 
raphy is that different vendor’s products 
cannot readily exchange messages, signa¬ 
tures, and keys, since no industry standard 
protocols have been defined for their data 
formats. The DES algorithm is widely 
used in the industry today because a stan¬ 
dard exists. While industry standards may 
not be a sufficient condition for wide ac¬ 
ceptance of public-key cryptosystems, I 
contend that they are likely to be a neces¬ 
sary condition. For this reason this article 
proposes a standard data format protocol 
for public-key cryptography. 


What is public-key 
cryptography? 

In conventional cryptosystems such as 
the DES, a single key is used for both en¬ 
cryption and decryption. This means that 
keys must be initially transmitted via 
secure channels so that both parties can 
know them before encrypted messages can 
be sent over insecure channels. This may 
be inconvenient. 

In public-key cryptosystems, there are 
two complementary keys: a publicly re¬ 
vealed encryption key, and a secret decryp¬ 
tion key. Each key is the functional inverse 
of the other key, such that using one of the 
keys on a message produces ciphertext that 
can be converted back to plaintext by the 
other key. Further, knowing the public key 
does not help you deduce the correspond¬ 
ing secret key. This produces two useful 
consequences. First, secret channels such 
as couriers are not required to transmit 
keys, because the intended recipient (in 
this discussion, a woman) of a message has 
already publicly revealed her encryption 
key. The encryption key can even be 
published in a public key directory. 
Anyone wishing to send the recipient a 
message can use that public encryption key 
to encrypt the message before sending it. 
Only that recipient can decipher the 
message, since only she possesses the cor¬ 
responding secret decryption key. Not 
even the sender (in this discussion, a man) 
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of the message can decrypt it, because he 
lacks the secret decryption key. 

The second consequence is useful for 
electronic mail and electronic funds trans¬ 
fer. A sender can “sign” a message by 
“decrypting” it with his secret decryption 
key. The recipient (or anyone else) can 
verify the validity of this signature by using 
the publicly revealed encryption key on the 
signed message. Here, the objective is 
authentication instead of secrecy. Forgery 
is impossible, because no one but the 
sender has the secret decryption key. Not 
even the recipient of the message can forge 
the signature or modify the message with¬ 
out disturbing the signature. The signer 
can’t later deny the signature’s validity, 
since he’s the only one who knows that 
secret key. 

The RSA algorithm 1 is the most popu¬ 
lar public-key algorithm today and can be 
licensed from RSA Data Security in Red¬ 
wood City, California. It is a cryptograph¬ 
ically strong algorithm, because to crack it 
appears to require factoring very large 
(100- to 200-digit) composite numbers, 
which using current technology would re¬ 
quire billions of years to accomplish. 
Mathematicians have been searching un¬ 
successfully for centuries for a fast method 
for factoring large numbers. 

The proposed protocol 

The protocol defined here applies to the 
encryption function, which might be 
thought of as an encryption “layer.” Any 
other data communication layers (for 
message blocking, noise immunity, check¬ 
sums, converting to hex digits for 7-bit 
ASCII channels, data compression, source 
and destination address encapsulation, or 
whatever) would operate independently of 
this protocol. The encryption function 
may be inserted anywhere in a multilay¬ 
ered ISO OSI-type network protocol, but 
might typically be found at some higher 
layer, such as the application or presenta¬ 
tion layer. Or the encryption function may 
operate in other environments without any 
other network layers, for example, to 
merely encrypt a file on a floppy disk for 
sending through the US mail. 

This protocol defines the data structures 
of RSA public and private (secret) keys, 
signatures, and encrypted messages. It op¬ 
tionally provides the necessary data fields 
to support a new faster method of com¬ 
puting the RSA formulas. It defines 
methods for bootstrapping into faster 


single-key encryption algorithms, while re¬ 
taining the convenience and functionality 
of public-key cryptography. It defines 
methods for producing RSA digital signa¬ 
tures for small “message digests,” which 
are faster and more compact than apply¬ 
ing the RSA signature to entire lengthy 
messages. The protocol also defines 
methods for selecting the proper key for 
decryption, and verifying that a message 
was successfully decrypted with that key, 
without human assistance. It defines a 
protocol for Cipher Block Chaining, 
which thwarts cryptanalysis by block fre¬ 
quency analysis. It also defines a means of 
protecting keys in an electronic mail net¬ 
work environment, by using signed Key 
Server Certificates. 


The RSA algorithm 

An encrypted message is calculated as 
follows: 

C = M e modulo n 

where M is the cleartext message in the 
range of 0 . . . n - 1, e is the RSA key en¬ 
cryption exponent, n is the common RSA 
key modulus, and C is the encrypted 
ciphertext in the range of 0 . . . n - 1. 

The message is decrypted as follows: 

M = C d modulo n 

where d is the RSA key decryption expo¬ 
nent. M, C, and n are defined above. 

From the two formulas above, you can 
see that the encryption key is the pair 
(n,e ), and the decryption key is the pair 
(n,d). Note that the modulus n is com¬ 
mon to both keys. Note also that (n,e) is 
made public, and ( n,d) is kept secret. 

Two large primes, p and q, are used to 
calculate n as 
n = p*q 

The security of the system in part lies in the 
difficulty in factoring n. 

Calculating keys a e, d, 
p, and q 


Methods for calculating appropriate 
values for p, q, e, and d, are explained at 
some length in references 2 and 3. 

It’s important to choose primes p and q 
in such a way that their product n is hard to 
factor. Rules governing the selection of p 
and q are 

1) p and q should differ in length by a 
few digits. This prevents them from being 


too close to the square root of n, which 
would make it easier to find p and q 
given n. 

2) The value G(n) = gcd (p- 1, q- 1) 
should be 2 (gcd means “greatest common 
divisor”). This number, G («), is the num¬ 
ber of “spare key sets” for a given 
modulus n. The bigger G («) is, the more 
keys there are that can be used to unlock 
your ciphers. The smallest possible value 
for G (ri) is 2, because both (p- 1) and 
(q- 1) must be even numbers. A poor 
choice of p and q could result in an 
Avogadro’s number of “spare” keys. 4 

3) (p- 1) should contain a large prime 
factor p' , and (p' - 1) should contain a 
large prime factor p". Similarly, (#-1) 
should contain a large prime factor q ', 
and (#' - 1) should contain a large prime 
factor#". 

There are many ways to generate a 
prime p such that p -1 has a large prime 
factor. One way is to first generate a large 
“random” prime p'. Then generate 
p = i*2*p' + 1, for / = 1,2, 3,5,7,11, 
13,17. . . 

and test p for primality for each small 
prime i. Keep doing this until you get a 
prime p. A fast probabilistic algorithm for 
testing primality is given in references 2 
and 3. Since p' must also have a large 
prime factor p" , you could use this same 
method to first generate the initial prime 
p' from a random prime p". Doit to get q 
from q' from q" , too. 

To calculate e and d, first calculate the 
Euler totient function <f> of n (defined as 
the number of positive integers less than n 
that are relatively prime to ri): 

0(«) = (/>-!)* (#-l) 

Since small values for e are more effi¬ 
cient, pick e in advance such that e is 
relatively prime to <f>(n ), that is, 
gcd[e, </>(/;)]= 1 

Use e to compute d such that d satisfies the 
following relationship: 

(e*d) mod <t>(n) = 1 
You would use Euclid’s algorithm 3 to 
calculate d as the multiplicative inverse of 
e in the “world” of mod <t> (n ). Note that 
it’s hard to calculate d without knowing 
0(«), which means you must know the 
prime factors p and q. That’s why the RSA 
cipher is so hard to crack. 

Another way to compute d from e is to 
use F(n ) instead of 0(n): 

( e*d) mod F(n) = 1, where F(n) = 
<t>(n)/G(ri) 

This is better because it tends to generate 
the smallest possible value for d that will 
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match up with e and n. This means your 
decryption computations will go faster. 4 

In practical implementations, it is sug¬ 
gested for performance reasons that the 
enciphering exponent e of a public key be a 
very small integer. Selecting a small e 
would speed up the encryption of mes¬ 
sages, without sacrificing security. Since 
the secret key d is large, it doesn’t matter 
that eis small. There’s no reason not to use 
the same value for everyone’s public key e, 
since they could all have different large 
secret key d’s and different common 
moduli. A good value to use for e might 
be 5. 

Gus Simmons of Sandia Labs has come 
up with an attack on using small encipher¬ 
ing exponents. If one uses e = 5, and sends 
5 identical messages enciphered under 5 
different moduli to 5 different recipients, 
then an eavesdropper could apply the 
Chinese Remainder Theorem to recover 
the plaintext, without learning the deci¬ 
pherment exponent d. This attack works 
the same way when e = 3, with 3 identical 
messages. 

However, this attack is prevented by 
using Cipher Block Chaining with a ran¬ 
dom Initialization Vector, which prevents 
the messages from being identical. See the 
section RSA Cipher Block Chaining 
below. This attack is also prevented by just 
using RSA to bootstrap into the DES with 
a unique random DES key used on each of 
the identical plaintext messages. This is ex¬ 
plained below in the section Bootstrapping 
Other Algorithms. 

Shortcut for RSA 
decryption 

Because of all the multiprecision arith¬ 
metic involved, RSA algorithms tend to be 
slow. 

Charles Merritt 4 has proposed an enor¬ 
mously streamlined method for decrypt¬ 
ing messages with the RSA secret key. In 
the worst case, his method is twice as fast 
as other traditional methods. It can be 
many times faster. 

Merritt’s method is as follows. First, at 
the time you generate the pair of keys 
calculate the value u (the multiplicative 
inverse of q mod p), such that it satisfies 
the equation 

(q*u) mod p = 1, assuming that p<q 
The value u can be calculated with Euclid’s 
algorithm. 3 

The precalculated value u is used later 
when messages are decrypted. Instead of 
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Figure 1. Multiprecision integer. 
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using the direct decryption formula M = 
C d mod n, the Chinese Remainder 
Theorem can be applied to get the faster 
equivalent algorithm given below: 

Pi = [(Cmodp) rfmod ^ _1) ] modp 
<72 = [(Cmod mod (?->)] mod q 
If pi = <72, then M = pi, and the algo¬ 
rithm halts. Otherwise, 

Pi =P2-(Qi modp ) 

If pi < 0, then pi = pi + p 
M = <72 + <q* l(Pi*u) mod p]> 

The precalculated value u is stored with 
the secret key, as described in the section 
on secret keys. 

While Merritt’s method is useful for 
decryption, it isn’t necessary to use it to 
speed up encryption, because the public 
exponent e can be a small integer. 

The rest of this article defines the 
various data format components of the 
protocol. 


Multiprecision integers 

The RSA algorithm makes extensive use 
of multiprecision arithmetic. The data 
structures throughout this protocol use the 
format shown in Figure 1 for a multipreci¬ 
sion integer. 

LENGTH is a one-byte field that gives 
the length in bytes of the unsigned integer 
that follows. The LENGTH value can be 
in the range of 0. . . 255, and does not in¬ 
clude itself in the length count. 

The multibyte unsigned integer value 
that follows starts with the Most Signifi¬ 
cant Byte, or MSB, as BYTE 1, and ends 
with the Least Significant Byte, or LSB, 
as BYTE N. There may be as many as 


255 bytes in this integer. No negative in¬ 
teger values are necessary for any RSA 
operation. 

If the LENGTH field is zero, then there 
are no value bytes following it. In that 
case, the value is zero. 

A multiprecision integer is said to be 
normalized if the MSB is nonzero. To nor¬ 
malize an unnormalized multiprecision in¬ 
teger, decrement the LENGTH byte and 
discard the MSB until it contains a 
nonzero value. 


Cipher control bytes 

The Cipher Control Byte, or CCB, is 
always found at the beginning of every 
RSA key and every RSA ciphertext 
message. The format is shown in Figure 2. 

The CCB fields have the following 
meanings (bit 0 is the least significant bit): 

• Bits 7-6: [CCB designator] 

Always set to 11 binary. 

• Bit 5: [KEY] 

1 means this is a key (public or secret). 

0 means this is an encrypted message. 

• Bit 4: [SECRET] 

1 means secret key. If this is a key, it is a 
secret key. If this is a message, it was en¬ 
crypted (signed) with a secret key. 

0 means public key. If this is a key, it is a 
public key. If this is a message, it was en¬ 
crypted with a public key. 

• Bit 3: [NESTED] 

1 means after you decrypt this cipher- 
text, expect another nested CCB, Single 
Key Byte, or Message Digest Byte (these 
are defined later) as the first byte of the 
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Figure 3. RSA public key. 


decrypted message. You have to go 
through another layer of processing. If the 
inner decrypted message starts with a 
CCB, this usually means the nested CCB’s 
SECRET bit contains a 1, indicating a 
signature. Note that you can have multiple 
layers of signatures. 

0 means not nested. This means there 
are no more layers of encryption in this 
message. Note that the NESTED bit only 
has meaning for a message, not for a key. 
So if this CCB’s KEY bit is 1, the 
NESTED bit should be set to 0. 

• Bits 2-0: Reserved for future expan¬ 
sion. Set to zero. 

Public keys 

The format for a public key is shown in 
Figure 3 and is explained as follows: 

• The CCB is defined above. For a key, 
the KEY bit is 1, and the NESTED bit is 
ignored. For a public key, the SECRET bit 
isO. 

• Modulus n and exponent e are both 
normalized multiprecision integers as 
defined above. 

• The modulus n is common to both the 
secret and public keys. The exponent e is 
part of the public key (n,e). In most im¬ 
plementations, e would probably be a very 
small integer, and would be the same value 
for everyone. 

Secret keys 

The format for a secret (private) key is 
similar to the format for a public key, with 
the addition of extra fields. Refer to Figure 
4 for the following explanation of the RSA 
secret key format: 

• For a secret key, the CCB’s SECRET 
bit is 1. Modulus n, exponents e and d, 
primes p and q, and multiplicative inverse 
u are all normalized multiprecision in¬ 
tegers as defined above. The secret key’s 
extra fields d, p, q, and u all have an addi¬ 
tional byte prepended to them. For d, this 


single byte prefix contains an ASCII d (64 
hex). For p, the prefix byte contains an 
ASCII p (70 hex). For q, the prefix byte 
contains an ASCII q (71 hex). For u, the 
prefix byte contains an ASCII u (75 hex). 
The reason for these tag byte prefixes is 
given below. 

• The modulus n is common to both the 
secret and public keys. The exponent e is 
part of the public key (n,e). 

• The exponent d is part of the secret 
key (n,d). The factors p and q are large 
prime numbers that satisfy the equation n 
= p*q, and u is the presolved mul¬ 
tiplicative inverse of q in the world of mod 

p. The quantities p, q, and u can enor¬ 
mously speed up the performance of an 
RSA implementation that uses them. 4 
Note that only the secret key can include 
them, because d can be calculated from A 

q, and e. 

An explanation for those tag byte pre¬ 
fixes is now in order. Earlier I presented a 
streamlined algorithm for RSA encryption 
that required using p, q, and u. Some im¬ 
plementors may have their own RSA short¬ 
cut algorithms that may use different quan¬ 
tities than these. As time goes on, better and 
faster shortcuts may be developed that re¬ 
quire using different prestored quantities 5 
(one example of this is Merritt’s suggestion 
that it may be possible to generate a secure 
modulus from three primes, allowing faster 
decryption via the Chinese Remainder 
Theorem. 4 ). We don’t want the protocol 
presented here to be obsoleted by new RSA 
shortcut algorithms. The additional secret 
key fields in Figure 4 may not always all be 
present. A different set of quantities may 
partially replace these quantities. That 
means their order of appearance cannot be 
relied on to identify them. We need a way to 
tell them apart. The tag byte prefixes helps 
us distinguish which is which. 

The multiprecision integer that im¬ 
mediately follows the ASCII d tag byte is 
guaranteed to contain the exponent d. It 
must always be present, in case you 
have to feed your secret key into an un¬ 
sophisticated RSA implementation that 
uses no shortcuts. The other extra key 
fields are optional and may change. The 
multiprecision integer that immediately 
follows the ASCII p tag byte always con¬ 
tains the prime p. And it’s the same ar¬ 
rangement for q and u. This also implies 
that the order in which these tagged quan¬ 
tities appears may be changed, since it is 
the tag byte that identifies which is which. 
Future values for these tag byte prefixes 
for future quantities need not always be a 
convenient ASCII character for the name 


of the quantity. It’s not used for display 
purposes. The prefix byte need only con¬ 
tain a unique agreed-upon value that can 
distinguish what quantity follows it, 
across different future RSA implementa¬ 
tions. As future RSA shortcuts emerge, 
protocol agreements can be made for what 
new fields will be used and what their tag 
byte prefixes will be. Note also that since 
secret keys are not exchanged between 
users of the protocol, there is not as great a 
need for secret keys to have uniform for¬ 
mat as there is for public keys. 


Preblocking and 
padding the message 

Message bandwidth expansion is an 
unavoidable characteristic of RSA encryp¬ 
tion, because of the necessary preblocking 
of the message. Before a plaintext message 
can be fed to an RSA algorithm either to 
be encrypted or digitally “signed,” it must 
be converted into an integer whose value is 
in the range 0 ... n-\, where n is the 
modulus. It’s easy to convert a message 
into an integer, because a message is just a 
series of bytes, and so is an integer. If the 
message is too long to fit in one of these 
multiprecision integer blocks in the range 0 
. . . n - 1, it can be broken into as many 
blocks as necessary. Each block is sepa¬ 
rately encrypted. Each block must start 
and end on byte boundaries. 

To ensure that the plaintext falls in the 
range 0 ... n- 1, plaintext blocks are 
always assumed by this protocol to be one 
byte shorter than the length of the nor¬ 
malized modulus n. For example, if you 
define n to be 36 bytes long, normalized, 
you can encipher 35-byte plaintext mes¬ 
sage blocks. This may seem slightly com¬ 
putationally wasteful, because it could 
mean more multiprecision arithmetic for 
encryption of a larger number of smaller 
blocks. But an implementor could mini¬ 
mize that by always generating a modulus 
n such that the MSB is 01 hex. This would 
mean that n would have only one wasted 
bit. This still guarantees that a 35-byte 
block of plaintext will already be in the 
range of 0 . . . n — 1, for a 36-byte n. The 
ciphertext block would be 36 bytes long, 
and the MSB of the ciphertext block may 
or may not turn out to be zero. With this 
method, blocking becomes trivial, requir¬ 
ing no multiprecision arithmetic of any 
sort. 

The last plaintext block in a message is 
usually shorter than the modulus 
LENGTH-1. This short block is left 
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justified and padded to fill out the re¬ 
quired length. It is padded with random or 
pseudorandom bits, except for the last 
byte of padding. The last byte of padding 
contains a count of how many bytes were 
used for padding. This byte includes itself 
in the count. For example, if there were 
only one byte of padding, the last (and 
only) byte of padding would contain a 1. If 
there were nine bytes of padding, the last 
pad byte would contain a 9, and the other 
eight bytes would contain random bit pat¬ 
terns. The receiver of the message would 
examine the last byte of padding to decide 
how many bytes of padding to strip off to 
reconstitute the plaintext. This means that 
the last plaintext block must contain at 
least one byte of padding; another way of 
putting it is that the last plaintext block 
must always be shorter than the modulus 
LENGTH - 1, before it is padded. 

But what if the last plaintext block is 
already just the right size for the modulus 
without padding? In that infrequent case, 
an extra zero-length plaintext block must 
be appended, with enough padding added 
to fill out the extra block to the entire 
modulus LENGTH - 1. This zero-length 
plaintext block meets the requirement that 
the last plaintext block must always be 
shorter than the modulus LENGTH - 1, 
before it is padded. This guarantees the 
last byte can always be trusted to give a 
correct pad count. 

Throughout this article, any situation 
calling for random padding of RSA blocks 
will mean using the padding conventions 
just described. In some special cases, such 
as for applying RSA signatures to message 
digests or certificates, nonrandom con¬ 
stant padding will be specified. This is used 
when more redundancy and predictability 
is desired in the material to be signed. The 
usefulness of the added redundancy is ex¬ 
plained in the sections Message digest 
signature blocks and Key server cer¬ 


tificates. Message digests and key server 
certificates already contain plenty of ran¬ 
domness. In constant padding, the final 
pad byte still contains the pad count, but 
the random bit patterns that normally 
precede the pad count byte are replaced by 
nonrandom bytes. These nonrandom pad 
bytes contain the natural numbers from 1 
to the value of the final pad count byte. 
For example, if there are nine bytes of pad¬ 
ding, these nine bytes would contain the 
consecutive values 1 through 9. 

Encrypted messages 

The format of a message RSA- 
encrypted for secrecy is shown in Figure 5 
and explained as follows: 

• The CCB is defined above. 

• The common modulus n and public 
exponent e (both normalized multipreci¬ 
sion integers as defined above) are copied 
from the key that was used to encrypt or 
sign the message that follows. 

• The common modulus is there to help 
the recipient find the corresponding secret 
key to decrypt the message. If this is a 
message signed with the sender’s secret key 
( n,d ), the public exponent e and the 
modulus n can be used as the correspond¬ 
ing public key to interpret the signature. 

• If an implementor decides not to in¬ 
clude the ( n,e ) values with a message 
because the recipient is guaranteed to 
know them, both fields must still be pres¬ 
ent as zeros (their LENGTH bytes are 
zero). There are circumstances where this 
is appropriate, as explained later. 

• The RSA Message Format Byte, or 
MFB, is defined below. 

• The message blocks that comprise the 
rest of the message are formatted as mul¬ 
tiprecision integers, except they have no 
LENGTH bytes. Their implicit LENGTH 
bytes are the same as the LENGTH byte 


for the modulus n (because they were com¬ 
puted modulo ri), and thus would be 
redundant if they were included. The 
blocks might not be normalized. Their 
values are all in the range of 0 . . . n - 1. 
When decrypted, these message blocks 
will produce plaintext blocks that are 
LENGTH-1 bytes long. 

• RSA-encrypted messages are ran¬ 
dom-padded at the end. This helps thwart 
cryptanalysis attacks that exploit cases 
where the content of short messages may 
be predictable. 

• The message header does not include 
a message block count, as this may be 
unknown when the message stream is be¬ 
ing generated. This protocol does not 
define how the end of the message stream 
is detected. This requires help from other 
layers. It may be implemented, for exam¬ 
ple, by detecting an end-of-file status 
returned from a lower-level disk I/O 
driver, or an end-of-message status re¬ 
turned from a lower network layer. 


Digital signatures 

There are two ways to sign a message: 
with a pure RSA signature, and with a 
Message Digest Signature Block, or 
MDSB. 

For a pure RSA Signature, user A (in 
this discussion, a man) would use his secret 
key ( nA,dA ) to encrypt a plaintext mes¬ 
sage. If secrecy is required, the ciphertext 
message, complete with its signature CCB, 
(n A.eA), and MFB prefix, would then be 
treated as plaintext and reblocked for en¬ 
cryption using the destination user B’s 
public key (nB,eB). User B (in this discus¬ 
sion, a woman) reverses these steps. First 
she uses her secret key (nB,dB) to decrypt 
the message, if it was encrypted. Then she 
uses A’s public key («A,eA) to decode the 
signature. This scheme works even if user 
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A and user B choose different-sized 
moduli. 

The format for a pure RSA-signed mes¬ 
sage is identical to the format of a pure 
RSA-encrypted message (see Figure 5), 
except the CCB’s SECRET bit is 1 instead 
of 0. 

The MDSB method to obtain digital 
signatures saves disk space and would 
generally be faster. More importantly, it is 
more secure against active wiretappers. 
For an explanation, see the section 
Message Digest Signature Blocks. 

RSA-signed messages are random- 
padded at the end. This could help prevent 
an active wiretapper from resubmitting a 
duplicate of an earlier signed message he 
or she may have intercepted. There may be 
some advantages to using all or part of a 
timestamp in the padding, if there is room. 
A better approach would be for users to 
put the timestamp in the message itself, 
but that is outside the control of this pro¬ 
tocol. 


Justification for the (n,e) 
message prefix 

First, it’s important to note that the 
common modulus n is always public, 
because it is part of both the public and 
secret key, so there’s no compromise of 
security by prepending the message with it. 
The same is true for the public exponent e. 
And since e is almost always only two 
bytes long (counting its LENGTH byte), it 
doesn’t cost much to include it. 

In the case of digital signatures, there 
may be a great many public keys to search 
through to discover the sender’s identity 
and verify the sender’s signature. Having 
the common modulus on hand would 
speed up that search. If e is also supplied, 
throughput can be improved by starting 
the RSA computations while the key 
search is underway. Of course, it’s still 
necessary to do the search, to verify that 
the alleged sender of the message actually 
owns the key that was supplied with the 
message. This is essential. 

The encryption function can find the 
right key in a modulus-keyed dictionary 
with fast simple compare operations, 
without going through lengthy trial 
decryption calculations, and without the 
help of a sophisticated human operator. It 
does not assume a sophisticated com¬ 
munications layer with source/destination 
message encapsulation to help find the 
right key to use. Users of one or more 


public-key cryptosystems may decide to 
use different key pairs in different cir¬ 
cumstances or across different systems. 
They may need help in choosing which of 
their own secret keys to use to decrypt a 
message addressed to them. 

It would be nice not to have to burden a 
different communications layer with 
knowledge of decisions made in the en¬ 
cryption “layer,” and vice-versa. There 
are a great many ways to represent a “user 
ID” across a great many operating systems 
and networks, and it may not always be 
unique to a user. Some systems may not 
even have stable user IDs at all. Using peo¬ 
ple’s names as user IDs won’t always 
work, as they may be spelled in multiple 
ways in different directories. Using the 
modulus as the user ID assumes nothing 
about the environment one is running in. 
While there is nothing to stop each user 
from having many moduli, it is guaranteed 
that there can be only one user per modu¬ 
lus. All this makes the modulus an airtight 
“mathematically pure” user ID tag ap¬ 
propriate to the encryption function. 

In implementations that have key 
servers available, there is a better way to 
tell the recipient which key to use to verify 
the signature on a signed message. Send 
your public key enclosed in a public key 
certificate signed by the key server along 
with the message. The recipient could then 
find a trustworthy copy of your public key 
in the certificate accompanying the 
message, without even having to look it up 
to verify that it’s really your key. This is ex¬ 
plained fully in the section on key server 
certificates. Since the recipient would then 
know which key to use to authenticate the 
signed message, you could omit the {n,e) 
message prefix from the signed message. 
Just set both of the length bytes for n and e 
to zero. Also note that the ( n,e ) message 
prefix may be optionally omitted in any 
circumstance where the recipient already 
knows which key to use. 


Message Format Byte, 
or MFB 

The MFB is found in the header of every 
RSA-encrypted message, just after the en¬ 
cryption exponent e, and just before the 
RSA message blocks begin. Unlike the 
CCB, it is found only in messages, not 
keys. The MFB describes some parameters 
regarding how the message was encrypted. 
The format of the MFB is shown in Figure 
6 and explained as follows: 


• Bit 7: [CBC] 

1 means Cipher Block Chaining is in ef¬ 
fect. See the section on Cipher Block 
Chaining for an explanation. 

0 means Cipher Block Chaining is not in 
effect. 

• Bit 6: [IVNZ] 

1 means the first RSA message block 
contains the enciphered CBC Initializa¬ 
tion Vector, or IV. It was inserted before 
the message was encrypted, and may be 
discarded after the message is decrypted. 
Note that the IVNZ bit only has meaning if 
the CBC bit is 1. 

0 means the first RSA message block 
contains user data, and there is no IV sup¬ 
plied in the message stream. Accordingly, 
the IV for the CBC chain is assumed to be 
all zeros. This is good for saving room, if 
the message is already random enough. 

• Bit 5: [CKS] 

1 means each message block contains a 
checksum byte to assist in determining if 
decryption was successful. The checksum 
is visible after decrypting the ciphertext. 
See the section Checksumming, below. 

0 means checksumming is not enabled. 
The message blocks do not contain a 
checksum byte, and thus can be used en¬ 
tirely for user data. 

• Bit 4: Reserved for future expansion. 
Set to zero. 

• Bits 3-0: [NBLOCKS] 

The NBLOCKS field is used for boot¬ 
strapping into a faster encryption method, 
and for creating message digest signature 
blocks. NBLOCKS contains the number 
of RSA message blocks to decrypt. If 
NBLOCKS is zero, it means decrypt all of 
the message blocks. If this field is nonzero 
(maximum value is 15), it directs the RSA 
encryption function to decrypt only that 
many (NBLOCKS) message blocks, then 
stop decrypting. The remainder of the 
message is just passed along as though it 
were plaintext. See the sections Bootstrap¬ 
ping other algorithms and Message digest 
signature blocks for further details. 

Cipher Block Chaining, 
or CBC, with RSA 

If the CBC bit is set in the RSA Message 
Format Byte, or MFB, then Cipher Block 
Chaining is in effect. 

The Cipher Block Chaining, or CBC, 
mode of RSA encryption offers some ad¬ 
vantages over the normal “codebook” 
mode. In CBC mode, each block’s en¬ 
cipherment depends on all the previous 
plaintext blocks in the message stream. 
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In normal RSA messages encrypted for 
secrecy, an eavesdropper could discover 
any consistent block-aligned data pat¬ 
terns, because each block of identical 
plaintext would produce a block of iden¬ 
tical ciphertext. This becomes especially 
true if entire messages are repeatedly 
transmitted. CBC mode can prevent con¬ 
sistent block-aligned patterns, particularly 
if a random initialization vector is chosen. 
Using a random IV with CBC turns iden¬ 
tical messages into unique messages, 
which thwarts attacks that exploit vulnera¬ 
bilities of sending identical messages. 

In normal RSA signatures, an active 
wiretapper could change the sequence of 
signed message blocks in a message stream 
without detection by the protocol. The 
RSA signature on each block would still be 
intact, but the message meaning may be 
altered by the block juggling. CBC mode 
makes it possible to detect if RSA signa¬ 
ture message blocks have been deleted or 
permuted in any way, because each block’s 
signature depends on the previous block. 
This depends heavily on the assumption 
that the receiver is smart enough to 
recognize that the deciphered plaintext has 
been garbled. 

(*BC has sometimes been used by DES 
applications to help protect against active 
wiretappers. This works for single-key 
cryptosystems like the DES, but public- 
key cryptosystems work differently. It’s 
important to remember that when CBC is 
applied to messages enciphered with the 
recipient’s public key, it only enhances 
secrecy against passive wiretappers—it 
does not enhance authentication against 
active wiretappers. As is always the case 
with RSA, authentication requires using 
RSA signatures, enciphered with the 
sender’s secret key, whether CBC is used 
or not. 

Using RSA signatures with CBC alone 
is not enough to protect against all cases of 
active wiretappers. A human reader can 
recognize the corruption of natural lan¬ 
guage text if it has been hit by an active 
wiretapper. But authentication of binary 
data requires the computer to recognize 
the corruption of data without human as¬ 
sistance. The best approach for this is to 
use signed message digests, which is ex¬ 
plained in the section Message Digest 
Signature Blocks. While using CBC 
doesn’t provide all that much additional 
confidence in authenticating RSA signa¬ 
tures, CBC does help quite a bit when used 
with RSA secrecy encryption. 

CBC with the RSA is shown in Figure 7. 
Before a block of plaintext is fed to the 


RSA encipherment function, it is first 
modified by exclusive-ORing, or XORing, 
it with the preceding block of ciphertext. 
In the case of the first block of plaintext, 
there isn’t any preceding block of cipher- 
text to XOR it with. In which case, an ex¬ 
tra block called the initialization vector, or 
IV, is inserted before the first block of real 
text to satisfy this requirement. The IV is 
XORed with the first block of plaintext 
before the first block of plaintext is fed to 
the RSA function. The IV is never exposed 
to wiretappers, because it is enciphered 
before it gets sent to the recipient. The IV 
is a special case, with the unenciphered IV 
acting as a block of ciphertext for the next 
XOR operation. 

The decrypted IV may be discarded by 
the recipient after the XOR operation. 
The IV can be any random or pseudoran¬ 
dom bit pattern, as long as it varies unpre- 
dictably from one message to the next. A 
timestamp might be a good thing to put in 
an IV, if the rest of the IV is unpredictable. 
Note that the unenciphered IV length is 


the same as the length of any other RSA 
plaintext message block. All but the most 
significant byte of each of the ciphertext 
blocks is used to XOR with the next 
plaintext block, which is one byte shorter 
than a ciphertext block. See Figure 7. 

An attack proposed by J. Hastad at 
MIT 6 exploits the use of small encipher¬ 
ment exponents. Suppose you send mul¬ 
tiple copies of the same message to dif¬ 
ferent people, and you use timestamps to 
induce message uniqueness. If the attacker 
knows or can deduce the timestamps, he 
can recover the plaintext by applying the 
Chinese Remainder Theorem. The same 
weakness exists if CBC is used and the IV is 
known to the attacker. This protocol’s 
practice of concealing the IV thwarts 
Hastad’s attack. 6 

If the MFB’s IVNZ, or IV NonZero, bit 
is zero, there isn’t any IV prepended to the 
encrypted message. The IV is implicitly 
zero in this case. This is useful when the 
message already contains a lot of ran- 
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Figure 8. Message digest Byte, or MDB. 


domness, and you want to save space and 
computational time. 

With Cipher Block Chaining, any trans¬ 
mission error in a single ciphertext block 
will propagate throughout the corre¬ 
sponding plaintext block and a portion of 
the following plaintext block at the receiv¬ 
ing end. 

Checksumming 

If the MFB’s CKS, or ChecKSum, bit is 
1, it means each plaintext message block 
contains a checksum byte that gets ap¬ 
pended prior to encryption. The checksum 
is visible after decrypting the ciphertext. 

It is not the responsibility of the encryp¬ 
tion protocol to detect transmission noise! 
that’s for other communication layers to 
handle. Nor can the checksum alone 
detect the work of a clever active wiretap¬ 
per; you need more than one byte’s worth 
of checksum protection for that. That’s 
what message digests are for. The 
checksum is there mostly to help deter¬ 
mine if the decryption was successful, in 
case you selected the wrong key. It’s also a 
good confidence builder when you are try¬ 
ing to make do with little or no error 
checking in lower communication layers. 

If CKS is enabled, each RSA message 
block has a checksum byte appended to it 
during the preblocking phase while it is 
still plaintext. This tells the recipient to 
strip off and discard the last byte after 
decrypting, during the post-unblocking 
phase. Note that this means the message 
block can hold one fewer byte of user data 
than it could if checksumming were not 
enabled. The checksum is a simple ad¬ 
ditive checksum, the sum of all the other 
bytes in the block modulo 256. A more 
sophisticated checksum algorithm such as 
a CRC is unnecessary because the check¬ 
sum is buried in an encrypted block that, if 
hit with any transmission noise or if a 
wrong key is used, would completely gar¬ 


ble the plaintext message block and 
checksum. 

This checksum is useful in situations 
where there may be no way that a human 
operator can inspect decrypted plaintext 
to see if it decrypted properly. If it were left 
up to other layers to detect a bad decryp¬ 
tion (not because of transmission noise, 
but perhaps because of a wrong choice of 
key), they may lack the knowledge of how 
to detect a bad message. This gives the en¬ 
cryption function the means to handle er¬ 
rors relating directly to encryption. The 
encryption function can then make an on- 
the-spot decision of what to do about a 
bad checksum, and can take some action. 

When using MDSBs, or RSA-encrypted 
single-key packets (see below), it is highly 
desirable to add some redundancy by 
using the checksum feature. That way, if a 
MDSB doesn’t check with the message, 
you can tell if it’s a bad signature or a bad 
message. Or if the single-key packet fails 
to correctly decrypt the attached message 
stream, you can tell if it’s a bad message 
stream or a bad single-key packet. 

As explained in the section Preblocking 
and Padding the Message, the last block of 
plaintext to be RSA-encrypted must be 
shorter than the size required by the 
modulus n. This last block is left-justified 
and padded during preblocking to fill out 
the block before the checksum is ap¬ 
pended to the end of the block. The pre¬ 
blocking phase is when you add the check¬ 
sum byte. The checksum byte reduces by 
one the amount of message data and pad¬ 
ding data that will fit in an RSA message 
block. So if you have a 36-byte modulus, 
and 20 bytes of message data, you would 
add 14 bytes of padding to the 20 message 
bytes, and 1 checksum byte, yielding a 
35-byte plaintext block to feed into the 
RSA function. This yields a 36-byte 
ciphertext block. If checksumming were 
not enabled, you would have used 15 bytes 
of padding. 


It may be desirable to keep a signature 
for a message around for a long time, in 
case the signature may be needed at a 
future date to settle authenticity disputes 
between the signator and the recipient. If 
the signature is formed by applying RSA 
to the entire message, both the plaintext 
copy and the RSA-signed copy would both 
have to be retained. If the message is 
lengthy, this could mean tying up a lot of 
disk space just to prove who sent the 
message. A way to condense the signature 
is needed. 

This can be solved by a more space- 
efficient approach that uses a one-way 
hashing algorithm to form a small message 
digest of the entire message. This digest is 
analogous to a checksum. Any tampering 
with the message, including interchanging 
or deleting message blocks, would cause a 
change in the message digest. The message 
digest could be signed with RSA, forming 
the Message Digest Signature Block, or 
MDSB. The storage requirements for 
keeping the signature around would be 
reduced to just one RSA message block. 
Only one copy of the lengthy message 
would need be to kept by the recipient- 
just the plaintext copy. 

There is another advantage to using 
message digests to authenticate data. If 
you are trying to authenticate human lan¬ 
guage text, a human reader can recognize 
the obvious corruption of the text if it has 
been hit by an active wiretapper. But if you 
want to authenticate binary data such as 
computer software or telemetry from an 
unmanned seismic monitoring station at a 
nuclear test site, you need the computer to 
recognize the corruption of data automati¬ 
cally, and in a timely manner. Using a 
message digest solves this problem. 

Suppose User A (in this discussion, a 
man) wants to send a signed message to 
User B (in this discussion, a woman). He 
would form a message digest of a lengthy 
message and prepend it to the plaintext 
message. Then, he would RSA-sign just 
the first block (the message digest) with his 
secret key, forming the MDSB, and set the 
CCB’s NESTED bit to 1, and the RMB’s 
NBLOCKS field to 1. Note that at this 
point, the entire message following the 
MDSB is still plaintext. If secrecy is not re¬ 
quired, this results in a nonsecret signed 
message that could be sent somewhere. If 
secrecy is required, however, User A could 
encrypt the entire signed message (all the 
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Figure 9. MDSB-signed message. 



way from the inner CCB to the end of the 
message plaintext) with User B’s public en¬ 
cryption key and send it to User B. 

User B would find the outermost MFB’s 
NBLOCKS field equal to zero, meaning 
she must RSA-decrypt all of the message 
blocks that follow. Also, the outer CCB’s 
NESTED bit would be 1, indicating she 
should expect another CCB, MDB, SKB, 
or Certificate Byte at the beginning of 
what she will decrypt. She would use her 
secret key on the whole message, and 
would then discover the nested MFB with 
a NBLOCKS field equal to 1, and the 
CCB’s NESTED bit set to 1. That 
NESTED bit would tell her to examine the 
first byte of what gets decrypted to look 
for another CCB, MDB, SKB, or Cer¬ 
tificate Byte. Only the first message block 
(containing the message digest) would be 
encrypted (signed), with the rest of the 
message left in plaintext. She would use 
User A’s public key to decrypt (“unsign”) 
the MDSB, and compare the message 
digest value with her own calculated 
message digest value for this message. If 
they are equal, the signature is valid. 

Note that an MDSB can be sent without 
the message following it. This can be 
useful in some circumstances. 

The first byte of a message digest has the 
format shown in Figure 8 and is explained 
as follows: 

• Bits 7-5: [MDB designator] 

Always set to 010 binary. Indicates this 
is a message digest byte. 


• Bit 4: [NESTED] 

Analogous to the NESTED bit in a 
CCB. If this bit is set, it means the very 
first byte of the plaintext message (the one 
that was used to create the message digest) 
is a CCB, an SKP, or a Certificate Byte. 
This is useful for cases where many people 
must each apply their signature to one 
message or one message digest, nesting 
their signatures. 

• Bits 3-0: [Message Digest Algorithm] 

Decimal value selects hashing algorithm 

used to create Message Digest: 

0: Unknown. Recipient has to know the 
algorithm by prearrangement. 

1: Meyer-Matyas iterative DES Message 
Digest algorithm (twice). 

2-4: Reserved for protocol expansion. 

5-15: Available for implementors. 

The MDSB is simply a message digest 
that has been signed by RSA encryption. 
The complete format for a message signed 
via an MDSB is shown in Figure 9 and ex¬ 
plained as follows: 

• A checksum in the MDSB is used to 
guarantee some redundancy (see the sec¬ 
tion on checksumming), so the MFB’s 
CKS bit (the MFB “S” bit in Figure 9) is 


Message digest 
algorithm 

There are several one-way hashing algo¬ 
rithms in the literature for computing a 


message digest, many of them vulnerable 
to known attacks. The algorithm must be 
good enough to prevent a forger who 
knows the original message from coming 
up with another message that still pro¬ 
duces the same message digest value. 
Meyer and Matyas at IBM 7 give a very 
good one-way hashing algorithm that uses 
the DES 8 iteratively to compute a pair of 
64-bit numbers (16 bytes) to make a 
message digest. 

For all multibyte numeric fields in a 
message digest, the MSB comes first, and 
the LSB comes last. 

If the MDB algorithm field is 1, the 
message digest is formed with the Meyer- 
Matyas iterative DES algorithm (applied 
in two passes, as explained later). 

The 64-bit vector / shown in Figure 10 is 
initially set to a random bit pattern, con¬ 
taining a 56-bit DES key, distributed over 
eight bytes. Each of these eight bytes con¬ 
tains seven key bits and one parity bit, with 
odd parity. The least significant bit of each 
of the eight bytes is a parity bit. This is the 
key format required by VLSI DES chips. 
As Figure 10 shows, each stage of output 
of the XOR is used as the key for the next 
stage. Only the most significant seven bits 
of each of the eight bytes are used as real 
key bits for the next DES stage. The last 
stage yields a full 64-bit hash function 
value h. The last message block should be 
left-justified and padded with zeros if it is 
less than 64 bits long. This padding is done 
only to compute the message digest, and 
does not become part of the message. All 
this produces a message digest comprised 
of the 64-bit /and the 64-bit hash function 
result h(M,I). 

There is a certain class of attacks, 
known as “birthday” attacks, that can be 
mounted with available supercomputers 
against any 64-bit hashing function. 9 
They are called birthday attacks because 
of the analogy of how surprisingly likely it 
is to find two people with the same birth¬ 
day in a small group. Using more bits of 
hashing function would make “birthday” 
attacks infeasible. This can be achieved by 
computing two different 64-bit hash func¬ 
tion values. 

When the MDB algorithm subfield is 1, 
the Meyer-Matyas algorithm is run twice 
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on the same message (in parallel), with two 
different random starting values for I. 
This produces a 64-bit / lt followed by a 
64-bit / 2 , followed by the 64-bit h\(M,I\), 
followed by the 64-bit A 2 (A/,/ 2 ). This 
creates a 33-byte message digest, counting 
the MDB. See Figure 11. Adding one byte 
for the checksum, and one more for the 
minimum padding required (since this 
would be the last and only block to be 
signed), this would require an RSA mod¬ 
ulus at least 36 bytes long, if you want to fit 
everything in one RSA message block. 

If the message digest is smaller than an 
RSA message block, it is constant-padded 
before it is signed. The constant padding 
adds redundancy, because it is a predict¬ 
able pattern that can be easily recognized. 
This helps us diagnose whether a bad 
MDSB is because of a wrong RSA key, 
or a bad message. Then it is RSA-signed to 
form the MDSB. The first real message 
block starts after the MDSB. 

There is nothing particularly illegal 
about using message digests without set¬ 
ting the MFB’s NBLOCKS field to 1. The 
NBLOCKS field could be zero, in which 


case the range of the signature extends 
beyond the message digest, and includes 
the rest of the message. The message digest 
is still padded the same way, and is still in 
its own separate RSA block. The message 
digest is computed in exactly the same 
manner as it would be if the signature did 
not cover the message itself. It is computed 
from the plaintext message before the 
message ever gets padded or preblocked or 
checksummed by the RSA function. This 


expensive belt-and-suspenders approach is 
described only here because it isn’t forbid¬ 
den by the protocol’s syntax. It is not likely 
to be worthwhile, since it’s better to just 
pick the best hashing algorithm available 
and trust it to represent your messages. 

Note that since the MDSB comes before 
the message, it would be difficult to con¬ 
struct an RSA “data pipeline” trans¬ 
mission device such as a modem that could 
generate this MDSB. This is because the 
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Figure 15. DES key packet. 


entire message must be read before the 
message digest can be computed. But since 
the encryption function does not know 
how to recognize the end of a message 
stream without help from some other pro¬ 
tocol layers, the MDSB must come at the 
beginning of a message, not the end. A 
more formidable difficulty with putting 
the MDSB at the end is that the initial 
64-bit vector / must be known, to start the 
computation of the hash function. This 
complicates the task of a pipeline device if 
it lacks buffers large enough to hold the 
entire message. It takes a real computer 
with random access addressing of the 
message to insert the MDSB at the begin¬ 
ning of the message. 

There is a possible implementation- 
specific solution to this restriction on 
“data pipeline” transmission devices, 
even though this protocol does not define 
or require it. One could send the two /vec¬ 
tors imbedded in an unsigned dummy 
message digest at the beginning, contain¬ 
ing two zeroed-out h hash function values. 
The message would begin immediately 
after this unpadded message digest. This 
would provide the /vectors needed to start 
computing the hash functions. Then the 
fully computed and signed MDSB could 
be later sent separately after the message, 
with the cooperation of other communica¬ 
tion layers. The latter MDSB would serve 
as the bona-fide one for checking and 
keeping in a signature log. 

Bootstrapping other 
algorithms 

Because the RSA algorithm tends to be 
slow, other faster single-key encryption al¬ 
gorithms may be desirable for some ap¬ 
plications. High-speed or high-volume ap¬ 
plications, for example. While there are 
other single-key fast algorithms that are as 
resistant to cracking as the RSA algo¬ 
rithm, they lack the “public-key” conve¬ 
nience of RSA. 

A good way to remedy this is to have 
just one RSA-encrypted block contain the 
key to a faster single-key encryption algo¬ 


rithm such as the DES, then send the rest 
of the message encrypted only with that 
single key. The RSA encryption function 
would handle and strip off the outer RSA 
CCB, the ( n,e ) pair, and the MFB, and 
then pass the rest of the message along as 
plaintext to be handled by the other en¬ 
cryption algorithm. The outer CCB’s 
NESTED bit is 1, so the protocol will ex¬ 
amine the first byte of the first RSA- 
decrypted message block, and should find 
a Single-Key Byte, or SKB, starting off a 
Single-Key Packet, or SKP (see the SKB 
and SKP structures, below). The single¬ 
key encryption algorithm is selected by the 
SKB. This approach improves the speed, 
while still retaining the public-key func¬ 
tionality of RSA. 

If the MFB’s NBLOCKS field is non¬ 
zero, it directs the RSA encryption func¬ 
tion to decrypt only that many (NBLOCKS) 
RSA message blocks, then stop decryp¬ 
ting. The remainder of the message is just 
passed along as though it were plaintext. 
Presumably the remainder of the message 
is encrypted using the single-key encryp¬ 
tion algorithm, if the first byte of the RSA- 
encrypted portion is an SKB. 

Note that this bootstrap encryption ap¬ 
proach is good for encrypting messages, 
but is unsuitable for signing messages. It’s 
not adequate for preventing authenticity 
disputes between the sender and the recipi¬ 
ent, because the recipient has access to the 
key sent in the SKP. 

It is common practice when applying 
the DES to use a master key and a session 
key. The master key, which rarely changes, 
is used only to encrypt session keys, which 
change with every message and are sent 
along with the message. Public-key cryp¬ 
tography obviates the need for a DES 
master key in most situations, because the 
RSA key serves the same role as a DES 
master key. 

The size and format of the rest of the 
SKP depends on the type of encryption al¬ 
gorithm used, as defined by the SKB’s 
five-bit algorithm field. The interpretation 
of the algorithm field values is described 
below. 

For all multibyte numeric fields in a 
SKP, as always, the most significant byte 


comes first, and the least significant byte 
comes last. 

For the single-key algorithms defined by 
this protocol, the following rules apply to 
the SKP: The SKP is random-padded in 
the usual way to fill it out to the size re¬ 
quired by the RSA modulus. Then it is 
RSA-encrypted. The SKP does not share 
its RSA block with the first part of the 
encrypted message that follows. The 
message starts after the end of the RSA 
block that contains the SKP. This means 
the RSA function must provide to the 
single-key function what it needs to 
separate the message from the SKP. Note 
that an RSA-enciphered SKP can be sent 
without a message following it. This can 
be useful in some circumstances. 

The complete format for a message boot¬ 
strap-encrypted is shown in Figure 12. 

Note that in the figure the CKS check¬ 
sum bit (the MFB’s “S” bit in the above 
diagram) may be optionally set to add some 
redundancy to the RSA-encrypted SKP. 

Boot-encryption can be used in com¬ 
bination with other features, as shown in 
Figure 13. In fact, boot-encrypting an 
MDSB-signed message is probably the 
most efficient and productive use of this 
protocol. It is likely to be the most fre¬ 
quently used method of sending messages. 

Single-key packet 

The first byte of a Single-Key Packet, or 
SKP, is called a single-key byte or SKB, 
and has this format shown in Figure 14 
and explained as follows: 

• Bits 7-6: [SKB designator] 

Always set to 10 binary. Indicates this is 
a single-key byte. 

• Bit 5: [NESTED] 

This means the same as the NESTED bit 
in a CCB. 

• Bits 4-0: [Single-Key Algorithm] 

Selects single-key algorithm used. 

Possible decimal values: 

0: Unknown. Recipient has to know al¬ 
gorithm by prearrangement. 

1: Use the Data Encryption Stan¬ 
dard. 8,10 ' 11 The rest of the single-key 
packet for DES is outlined below. 

2-4: Reserved for protocol expansion. 

5-31: Available for implementors. 

For a single-key algorithm specifying the 
DES, the entire single-key packet is 18 
bytes long. The rest of the SKP (the next 17 
bytes) is shown in Figure 15 and defined as 
follows: 
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Figure 17. User identifier. 


• Byte 2 is the DES mode byte specify¬ 
ing the method of DES encryption. This 
byte is divided into two subfields of bits 
6-7 and bits 0-5. It may have values in the 
range of 0-128, which mean: 

[OOxxxxxx] binary, or 0-63: Use DES in 
Cipher Feed Back, or CFB, mode, as 
defined in reference 10. The low order 6 
bits contain a value in the range 0-63, 
which, when incremented by 1, gives the 
CFB feedback unit size in bits. This value 
of 0-63 corresponds to feedback unit sizes 
in the range of 1-64. The only feedback 
unit sizes required to support this protocol 
are 8 and 64 bits. Other sizes are allowed, 
but are not guaranteed support by all com¬ 
plying implementations. If the last 
message block (the terminal block) is 
shorter than the feedback unit size, only 
the left subset of the last key block is used 
on the terminal block. 

[Olxxxxxx] binary, or 64-127 : Use DES 
in Cipher Block Chaining, or CBC, mode, 
with terminal block padding. The terminal 
block is padded with zeros (nulls). The low 
order 6 bits contain a value in the range 
0-63, which gives the number of bits of 
padding required to fill out the terminal 
block to 64 bits. If the padding size is not 
known, use the value 0 for the 6-bit value. 
If the padding size is known to be really 
zero (no padding needed), set the DES 
mode byte to 128, which specifies CBC 
mode with terminal block truncation. This 
is still correct because when the terminal 
block is a full 64 bits, there is no functional 
difference between terminal block pad¬ 
ding and terminal block truncation. 

[10000000] binary, or 128: Use DES in 
CBC mode, with terminal block trunca¬ 
tion, as defined in reference 10. The low 
order 6 bits are zero. If there is a short ter¬ 
minal block, it is enciphered by encrypting 
the previous cipher block in the ECB mode 
and XORing the resulting enciphered 
cipher block to the terminal data block. 
Only the left subset of the terminal block is 
saved. This is equivalent to converting to 
CFB mode for the short terminal block. If 
the entire message is less than 64 bits long, 
the IV takes the place of the previous 
cipher block. 


• Bytes 3-10 contain the 56-bit DES key, 
distributed over eight bytes. Each byte 
contains seven key bits and one parity bit, 
with odd parity. The least significant bit of 
each of the eight bytes is a parity bit. These 
parity bits are not for noise immunity in 
the protocol, since other communication 
layers must take care of that. This is the 
key format required by nearly all VLSI 
DES chips. 12 

• Bytes 11-18 contain the 64-bit DES IV. 

Key server certificates 

Denning 13 presents a good case for the 
usefulness of signed key server certificates 
as a means of protecting keys in an elec¬ 
tronic mail network environment. Con¬ 
sider the case of an active wiretapper who 
could pretend to be the key server, or could 
somehow gain write-access to a key 
server’s public key directory. By substi¬ 
tuting his own public key for someone 
else’s in the public key directory, he can 
fool other users into using his key to en¬ 
crypt a message intended for someone 
else. Then he can read someone else’s 
messages. 

This problem can be solved by requiring 
public keys from the key server to be en¬ 
capsulated in a “certificate” signed by the 
key server (see Figure 21). No one could 
fake the key server’s RSA signature on the 
public key certificate, unless he knew the 
key server’s secret key. 

It is still necessary to ensure that the key 
server’s public key is correctly distributed 
to the public. One way to handle this is to 
publish the key server’s public key in some 
widely disseminated physical media, such 
as a printed phone book. Or it could be 
done via a face-to-face meeting with a 
representative of the key server. Such a 
meeting would be a good opportunity for 
a user to give his or her own public key to 
the key server for inclusion in the key 
server’s public key directory. 

All key server certificates contain time- 
stamps, user identifiers, and public keys, 
as described below. 

In addition to public key certificates, 
Denning describes other types of key 


server certificates that are useful: a sig¬ 
nature certificate, and a key compromise 
certificate. These other certificates are 
useful for dealing with the problem of 
what happens when someone’s secret key 
gets compromised. Their use requires the 
key server to maintain an on-line certificate 
log to provide an audit trail of certain 
events. The following events are logged: 

1) Registration of someone’s public 
key, by appending a public key certificate 
(see Figure 18) to the log. 

2) Registration of a signature, by ap¬ 
pending a signature certificate (see Figure 
19) to the log. One could regard a signa¬ 
ture “legally binding” if it has been 
entered into the log. 

3) Notification of the compromise of 
someone’s secret key, by appending a key 
compromise certificate (see Figure 20) to 
the log. Any signatures created with this 
compromised key after this certificate’s 
timestamp can be disavowed by the ap¬ 
parent signator. 

Anyone can read the certificate log, but 
only the key server can write it. A good im¬ 
plementation would have the certificate 
log on write-once media, such as optical 
disk, in a physically secure environment. 
The mere existence of such a log could help 
deter forgers. Denning describes in detail 
how this certificate log is managed and 
how it is used to detect and recover from 
key compromises, including the compro¬ 
mise of the key server’s own secret key. A 
detailed discussion of how all this works is 
beyond the scope of this article. See 
reference 13. Of course, not all public-key 
implementations need be this extravagant, 
and may not even have a need for key 
servers or their certificates at all. 

The first byte of a key server certificate 
has this format: [Ollxxxxx] 

• Bits 7-5: [Certificate designator] 

Always set to 011 binary. Indicates this 

is a Certificate Byte. 

• Bits 4-0: [Certificate type] 

Decimal value (0-31) selects type of cer¬ 
tificate: 

0: Unknown. User has to somehow 
know it already. 

1: Public Key Certificate (T, A, EA) 
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2: Signature Certificate (T, A, EA, X) 
3: Private Key Compromise Certificate 
(T, A, EA, XCOMP ) 

4-31: reserved. 

The fields of the various key server cer¬ 
tificates mean: 

T = timestamp (see Figure 16), 

A = user A’s identifier (see Figure 17), 
Ea = Public key (n A ,e A ), 

X = message digest signature block of 
any message, and 

XCOMP = MDSB of ASCII message 
string: “KEY COMPROMISED.” 

The timestamp (Figure 16) is a 32-bit un¬ 
signed integer of seconds elapsed since 
1970 Jan 1 at 00:00:00 GMT. This is the 
format used by Unix for timestamps. It 
would be easy to generate on any machine 
that could be used as a key server. Using 
GMT for the time avoids problems with 


daylight savings time, and problems with 
users and key servers being in different 
time zones. The MSB of the timestamp in¬ 
teger comes first. 

The user identifier format (Figure 17) is 
one length byte followed by that many 
data bytes, not to exceed 255 data bytes. 
The length byte does not include itself in 
the byte count. The type of data in the user 
identifier data bytes is entirely implemen¬ 
tation dependent, and may contain its own 
subfields. For instance, it could be some¬ 
one’s name or account number, or even a 
mailing label, complete with carriage 
returns and linefeeds. 

The key server creates a signed key 
server certificate by creating a message 
digest of the certificate and signing it, thus 
creating a message digest signature block. 
As always, the message digest is constant- 
padded before the signature is applied, 


and checksumming is used to guarantee 
some redundancy. The NESTED bit is set 
in the message digest’s MDB, to indicate 
that the first byte of the signed material is a 
Certificate Byte. The certificate itself (in 
plaintext form) immediately follows the 
MDSB. See Figures 18 to 21. 

It would be most useful to send a signed 
key server certificate prepended to every 
signed message. That way, the recipient 
need not look up the key to be confident of 
using the right key. The key server’s 
signature on the public key certificate ac¬ 
companying the message would be con¬ 
vincing enough. In fact, if you were to 
send a signed message to someone with an 
attached public key certificate signed by 
the key server, there would be no need to 
include the usual ( n,e) prefix to the 
message signature. They could be omitted 
by zeroing their length bytes. The recipient 
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Figure 22. Encrypted signed message with signed key server certificate. 


would get your public key from the at¬ 
tached public key certificate you sent. This 
practice is strongly recommended for any 
implementation that includes key servers. 
Figure 22 shows an example of this com¬ 
bined with boot encryption for secrecy. 

Note that since key servers are not 
necessary or appropriate for all public-key 
cryptosystems to function, key server cer¬ 
tificates need only be implemented to the 
extent deemed appropriate by the im¬ 
plementor. 


S ince 1977, the DES has flourished 
under a standards regime. That’s 
also how long public-key cryptosys¬ 
tems have been around. Yet there has been 
no movement toward public-key stan¬ 
dards in the United States. It’s about time 
things got moving in that direction. These 
RSA public-key protocols could serve as 
an ad-hoc standard in the personal com¬ 
puter industry. They would allow 
messages, signatures, and keys to be sent 
between users of different vendor’s hard¬ 
ware and software. These protocols are 
general enough and rich enough to serve a 
wide spectrum of applications in office 
automation, electronic funds transfer, and 
commercial electronic mail. It will be 
easier for the paperless office to become a 
reality when we overcome the obstacle of 
keeping a hardcopy of signed documents. 
In the private realm personal computer 
users will be able to send secure electronic 
mail via remote bulletin board systems. 

Your participation and suggestions are 
welcome. As the user community re¬ 
sponds with suggestions, these protocols 
will likely evolve. With enough industry 
interest, the protocols could evolve into an 
ANSI or NBS standard, leading to wider 
acceptance and use of public-key cryp¬ 
tography. □ 
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Database 

management systems 
should provide 
temporal support 
directly. Four types of 
databases are 
differentiated by their 
ability to represent 
temporal information. 
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T ime is an essential part of infor¬ 
mation about the constantly evolv¬ 
ing real world. Facts or data need to 
be interpreted in the context of time. 
Causal relationships among events or 
entities are embedded in the temporal 
information. Time is a universal attribute 
in most information management applica¬ 
tions and deserves special treatment as 
such. 

Databases supposedly model reality, 
but conventional database management 
systems (DBMSs) lack the capability to 
record and process time-varying aspects of 
the real world. With increasing sophistica¬ 
tion of DBMS applications, the lack of 
temporal support raises serious problems 
in many cases. For example, conventional 
DBMSs cannot support historical queries 
about past status, let alone trend analysis 
(essential for applications like decision 
support systems). There is no way to repre¬ 
sent retroactive or proactive changes, 
while support for error correction or audit 
trail necessitates costly maintenance of 
backups, checkpoints, or transaction logs 
to preserve past states. There is a growing 
interest in applying database methods for 
version control and design management in 
computer-aided design, requiring capa¬ 
bilities to store and process time- 
dependent data. Without temporal sup¬ 
port from the system, many applications 
have been forced to manage temporal 
information in an ad-hoc manner. 

The need to provide temporal support 
in DBMSs has been recognized for at least 
a decade. A bibliographical survey in 1982 
contained about 70 articles relating time 
and information processing, 1 and at least 
90 more articles have appeared since then. 
Recently, the rapid decrease of storage 
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costs, coupled with the emergence of 
promising new mass storage technologies 
such as optical disks, 2 has amplified in¬ 
terest in database management systems 
with version management or temporal 
support. George Copeland maintained 
that 

... as the price of hardware continues 
to plummet, thresholds are eventually 
reached at which these compromises [to 
achieve hardware efficiency] must be re¬ 
balanced in order to minimize the total 
cost of a system. ... If the deletion 
mechanism common to most database 
systems today is replaced by a non-dele¬ 
tion policy . . . , then these systems will 
realize significant improvements in 
functionality, integrity, availability, and 
simplicity. 3 

Gio Wiederhold also observed, in a review 
of the present state of database technology 
and its future, that 

The availability of ever greater and less 
expensive storage devices has removed 
the impediment that prevented keeping 
very detailed or extensive historical 
information in on-line databases. . . . 

An immediate effect of these changes 
will be the retention of past data ver¬ 
sions over long periods. 4 

In the past five years, numerous 
schemes have been proposed to support 
temporal information processing in 
database management systems by incor¬ 
porating one or more time attributes. 
However, there has been some confusion 
concerning terminology and the definition 
of these time attributes. In this article we 
describe a taxonomy of time consisting of 
three distinct time concepts for use in data¬ 
bases. 5 Using the taxonomy, we define 
four types of databases, differentiated by 
their ability to support these time concepts 
and processing of temporal information. 
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Figure 1.A snapshot relation. Figure 2. A rollback relation. 




The taxonomy 

Although the following discussion is 
based on the relational model, analogous 
arguments also apply to hierarchical or 
network models. 

Snapshot databases. Conventional 
databases model an enterprise as it 
changes dynamically by a snapshot at a 
particular point in time. A state or an in¬ 
stance of a database is its current content, 
which does not necessarily reflect the cur¬ 
rent status of the enterprise. The state of a 
database is updated using data manipula¬ 
tion operations such as insertion, deletion, 
or replacement, taking effect as soon as 
they are committed. In this process, past 
states of the database, representing those 
of the enterprise, are discarded and for¬ 
gotten. We term this type of database a 
snapshot database. 

In the relational model, a database is a 
collection of relations. Each relation con¬ 
sists of a set of tuples with the same set of 
attributes and is usually represented as a 
two-dimensional table (see Figure 1). As 
changes occur in the enterprise, this table 
is updated appropriately. For example, at 
a certain moment an instance of the rela¬ 
tion Faculty with the two attributes Name 
and Rank may be 

Name i Rank 


Merrie Associate Professor 

Tom I Associate Professor 


and a query in Quel (a tuple calculus-based 
language for the Ingres database manage¬ 
ment system 6 ) as to Merrie’s rank, 

range of f is Faculty 

retrieve (f.Rank) 

where f.Name = "Merrie" 
yields the rank of associate professor. 

In many situations this snapshot data¬ 
base is inadequate. For example, it cannot 
answer queries such as 

• What was Merrie’s rank two years 
ago? (historical query) 

• How did the number of faculty 
change over the last five years? (trend 
analysis) 

nor record facts like 

• Merrie was promoted to a full pro¬ 
fessor starting last month, (retro¬ 
active change) 

• Lee is joining the faculty next month, 
(proactive change) 

Without system support in this respect, 
many applications have had to maintain 
and handle temporal information in an ad- 
hoc manner. For instance, many person¬ 
nel databases attempt to record the entire 
employment history of the company’s 
employees. That some of the attributes 
record time and that only a subset of the 
employees actually work for the company 
at any particular point in time do not con¬ 
cern the DBMS itself. The DBMS provides 
no facility for interpretation or manipula¬ 
tion of this information; such operations 
must be handled by specially-written 
application programs. The fact that data 
vary over time is not an application- 


specific aspect. This aspect should be sup¬ 
ported in a general fashion by the DBMS, 
rather than by application programs. 

Rollback databases. One approach to 
resolving the above deficiencies is to store 
all past states, indexed by time, of the 
snapshot database as it evolves. Such an 
approach requires a representation of 
transaction time, the time the information 
was stored in the database. Under this ap¬ 
proach a relation can be illustrated con¬ 
ceptually in three dimensions (see Figure 
2), with transaction time serving as the 
third axis. The relation can be regarded as 
a sequence of snapshot relations (termed 
snapshot states) indexed by time. By mov¬ 
ing along the time axis and selecting a par¬ 
ticular snapshot state, it is possible to get a 
snapshot of the relation at some time in the 
past and make queries about it (a snapshot 
relation). The operation of selecting a 
snapshot state is termed rollback, and a 
database supporting it is termed a rollback 
database. 

Changes to a rollback database may be 
made only to the most recent snapshot 
state. The relation illustrated in Figure 2 
had three transactions applied to it, start¬ 
ing from a null relation: (1) addition of 
three tuples, (2) addition of one tuple, and 
(3) deletion of one tuple (entered in the 
first transaction) and addition of another 
tuple. Each transaction results in a new 
shapshot state being appended to the front 
of the time axis. Once a transaction is com¬ 
mitted, the snapshot states in the rollback 
relation may not be altered. 
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The distinction between snapshot data¬ 
bases and rollback databases is that the lat¬ 
ter have the ability to return to any previ¬ 
ous state to execute a snapshot query. Any 
query language can be converted to one 
that can query a rollback database by 
adding a clause effecting the rollback 
operation. TQuel (for Temporal QUEry 
Language), 7 an extension of Quel for 
temporal databases, augments the retrieve 
statement with an as of clause to specify 
the relevant transaction time. The TQuel 
query 

range of f is Faculty 

retrieve (f.Rank) 
where f.Name = "Merrie" 
as of "September 1978" 
on a rollback Faculty relation will find 
Merrie’s rank as of September 1978. The 
result of a query on a rollback database is a 
pure snapshot relation. 

One limitation of supporting transac¬ 
tion time is that the history of database 
activities, rather than the history of the 
real world, is recorded. A tuple becomes 
effective as soon as it is entered into the 
database, as in a snapshot database. There 
is no way to record retroactive/proactive 
changes, nor to correct errors in past 
tuples. Errors can sometimes be over¬ 
ridden (if they are in the current state), but 
they cannot be forgotten. For instance, if 
it were discovered that Merrie’s promo¬ 
tion had occurred earlier than previously 
recorded, this error could not be corrected 
in a rollback database; the query given 
above would continue to respond with the 
incorrect rank. 

Historical databases. While rollback 
databases record a sequence of snapshot 
states, historical databases record a single 
historical state per relation. As errors are 
discovered, they are corrected by modify¬ 
ing the database. Previous states of the 
database itself are not retained, so it is not 
possible to view the database as it was in 
the past. No record is kept of the errors 
corrected. Historical databases resemble 
snapshot databases in this respect. 
Historical databases support valid time, 
the time when the relationship in the enter¬ 
prise being modeled was valid. 

The semantics of valid time are closely 
related to reality, hence more complex 
than the semantics of transaction time 
concerned with database activities. There¬ 
fore, historical databases need sophisti¬ 
cated operations to manipulate the com¬ 
plex semantics of valid time adequately. 
TQuel supports such queries (termed his¬ 
torical queries) by augmenting the retrieve 


statement with a valid clause to specify 
how the implicit time attribute is com¬ 
puted and a when predicate to specify the 
temporal relationship of tuples participa¬ 
ting in a derivation. These added con¬ 
structs handle complex temporal relation¬ 
ships such as begin of, precede, and 
overlap. For example, the TQuel query 
requesting Merrie’s rank when Tom ar¬ 
rived is 

range of fl is Faculty 
range of f2 is Faculty 
retrieve (fl.Rank) 

where fl.Name = "Merrie" and 
f2.Name = "Tom" 
when fl overlap begin of f2 
The derived relation is also a historical re¬ 
lation that can be used in further historical 
queries. 

Another distinction between historical 
and rollback databases is that historical 
DBMSs support arbitrary modification, 
whereas rollback DBMSs only allow snap¬ 
shot states to be appended. The same se¬ 
quence of transactions that resulted in the 
rollback relation in Figure 2 will result in 
the historical relation in Figure 3, where 
the label of the time axis indicates the valid 
time. However, the historical relation can 
show that a later transaction has changed 
the time when a tuple takes effect in the 
relation, which is not possible on a roll¬ 
back relation. Rollback DBMSs can roll 
back to an incorrect previous snapshot 
relation; historical DBMSs can represent 
current knowledge about the past. 

Temporal databases. Benefits of both 
approaches can be combined by support¬ 
ing both transaction time and valid time in 
the same relation. While a rollback 
database views stored tuples, whether 
valid or not, as of some moment in time, 
and a historical database always views 
tuples valid at some moment as of now, a 
temporal database can view tuples valid at 
some moment seen as of some other mo¬ 
ment, thereby completely capturing the 
history of retroactive/proactive changes. 
The user of a temporal DBMS can exam¬ 
ine historical information from the view¬ 
point of a previous state of the database; 
both kinds of time may be manipulated in 
a query. 

We use the term temporal database to 
emphasize the need for both valid time and 
transaction time in handling temporal in¬ 
formation. Since there are two orthogonal 
time axes involved now, temporal rela¬ 
tions should be illustrated in four dimen¬ 
sions (Figure 4 shows a single temporal 
relation). 


A temporal relation may be regarded as 
a sequence of historical states, each a com¬ 
plete historical relation. The rollback 
operation on a temporal relation selects a 
particular historical state, on which a his¬ 
torical query can be executed. Each trans¬ 
action causes a new historical state to be 
created; hence, temporal relations are 
append-only. The temporal relation in 
Figure 4 is the result of four transactions, 
starting from a null relation: (1) three 
tuples were added, (2) one tuple was 
added, (3) one tuple was added and an ex¬ 
isting one deleted, and (4) one tuple was 
modified so that it started at a later valid 

Since TQuel supports both historical 
queries and rollback operations, it can be 
used to query temporal databases. An ex¬ 
ample is the TQuel query 
range of fl is Faculty 
range of f2 is Faculty 
retrieve (fl.Rank) 

where fl.Name = "Merrie" and 
f2.Name = "Tom" 
when fl overlap begin of f2 
as of "January 1979" 

that determines Merrie’s rank when Tom 
arrived, according to the state of the 
database as of January 1979. This derived 
relation is a temporal relation, so further 
temporal relations can be derived from it. 
The answer may differ if a similar query is 
made as of October 1978 and if her pro¬ 
motion was not yet recorded by that time. 

User-defined time. User-defined time is 
necessary when additional temporal infor¬ 
mation, not handled by transaction or 
valid time, is stored in the database. The 
values of user-defined temporal attributes 
are not interpreted by the DBMS and are 
thus the easiest to support; only an inter¬ 
nal representation and input/output func¬ 
tions are needed. Such attributes will then 
occur in the relation scheme. Multiple rep¬ 
resentations are also possible, each associ¬ 
ated with input and output functions. As 
an example of user-defined time, consider 
a Promotion relation with three attributes: 
Name, Rank, and Approved-Date. The 
Approved-Date (a user-defined time) is 
the date when the promotion committee 
approved the promotion; the valid time is 
the date when the promotion will take ef¬ 
fect; and the transaction time is the date 
the information concerning the promo¬ 
tion was stored in the database. 

An analogy. A simple analogy will help 
clarify the subtle differences among the 
four types of databases categorized above. 
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Figure 5. Types of databases. 
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Figure 6. Attributes of the four types of 
databases. 


First, a snapshot relation can be com¬ 
pared to the latest payroll stub showing the 
current position of the recipient. If the 
person gets a promotion, the next stub 
shows the new rank, but there is no way to 
find out about a past rank from the latest 
stub. 

If all the payroll stubs are carefully col¬ 
lected without discarding any of them, as 
some people do, it is possible to determine 
the rank as of some time in the past from 
the stub of that period. This collection of 
payroll stubs can be compared to a roll¬ 
back relation, a slice of which is a snapshot 
relation comparable to a payroll stub. 
These stubs will be printed in indelible ink, 
so that it will not be possible to make 
changes to payroll stubs of the past, even 
when there is a retroactive promotion or 
an error in last year’s salary. 

A historical relation can be compared to 
a resume, containing the history of job 
positions a person held up through the 
moment the resume was prepared. If an 
error is found in the resume, or if the per¬ 
son gets a promotion, a new resume re¬ 
flecting the change is in order. The current 
resume should always be up to date. 

A temporal relation can be considered 
as a collection of all such resumes marked 
by the date when each of them was pre¬ 
pared. It is possible and often interesting 
to go back to an old resume and read 
about the personal data as known at some 
past moment. 


An analogy for user-defined time would 
be the date printed on each payroll stub in¬ 
dicating when the pay period started. Note 
that this date does not necessarily corre¬ 
spond to the date the check (or the pre¬ 
vious one) was issued. 

Summary of taxonomy. Three kinds of 
time—transaction time, valid time, and 
user-defined time—were introduced, re¬ 
sulting in a categorization of the types of 
database management systems based on 
their support for handling temporal infor¬ 
mation. As shown in Figure 5, transaction 
time and valid time define the two orthog¬ 
onal capabilities of rollback operations 
and historical queries, thereby differen¬ 
tiating four types of databases: snapshot, 
rollback, historical, and temporal. 

Support of rollback operations requires 
the incorporation of transaction time, 
which concerns the representation. Sup¬ 
port of historical queries requires the in¬ 
corporation of valid time, which is associ¬ 
ated with reality. Support of user-defined 
time is orthogonal to support of historical 
queries or rollback operations. Hence, the 
three kinds of time actually define eight 
different types of databases. The taxon¬ 
omy presented here defines four types 
based on their support of transaction and 
valid time (see Figure 6). Each of these 
types may or may not support user- 
defined time. However, we note that user- 
defined time is much closer to valid time 
than to transaction time, in that both valid 
time and user-defined time are concerned 
with reality itself, whereas transaction 
time involves only the model of reality (the 
database). DBMSs (and their query lan¬ 
guages) purporting to provide full tempor¬ 
al support should handle all three kinds of 
time. 

An example 

The following example highlights the 
similarities and differences among the 
four types of relations, snapshot, roll¬ 
back, historical, and temporal. We first 
create an empty relation for each of the 
four types using TQuel create statements: 

create Snapshot (Name = c20. Rank = 
c20) 

create persistent Rollback (Name = c20. 
Rank = c20) 

create interval Historical (Name = c20. 
Rank = c20) 

create persistent interval Temporal (Name 
= c20. Rank = c20) 
These are the relations alluded to earlier, 
namely, the latest payroll check (snapshot). 


the collection of all past payroll stubs 
(rollback), the most current resume 
(historical), and the collection of all past 
resumes (temporal). 

Starting with these empty relations, a 
series of update operations are applied to 
each of them. After each update opera¬ 
tion, the states of four relations are dis¬ 
played: the snapshot relation in a conven¬ 
tional format as a single snapshot state, 
the rollback relation as a sequence of snap¬ 
shot states, the historical relation as a 
single historical state, and the temporal 
relation as a sequence of historical states. 
Several queries on these relations focus on 
what information is and, more important¬ 
ly, is not represented in each relation. 

Merrie joins as an instructor. In Sep¬ 
tember 1973, the following statement is 
executed: 

append to ? (Name = "Merrie", Rank = 
"Instructor") 

In these examples, the “?” symbol would 
be replaced by the name of a relation: 
snapshot, rollback, historical, or tem¬ 
poral. 

The four relations resulting from the 
execution of this statement are almost 
identical (see Figure 7). The snapshot rela¬ 
tion shows that Merrie is currently an in¬ 
structor. The rollback relation contains a 
single snapshot state created on September 
1973 (the transaction time that indexes the 
snapshot states is shown following the 
state), indicating that Merrie started 
receiving payroll checks made out to “In¬ 
structor Merrie” from September 1973. 
The historical relation indicates that Mer¬ 
rie has been hired as an instructor (the 
valid time for each tuple in the historical 
state is shown to the left of the tuple); there 
is currently one line on Merrie’s resume. 
The temporal relation contains one 
historical state, containing one tuple; 
analogously, there is one resume with one 
entry in Merrie’s resume file. 

If we asked back in October 1973 
“What was Merrie’s rank?”, 
range of f is ? 
retrieve (f.Rank) 

where f.Name = "Merrie" 
the same information would be returned 
from all four relations (“Instructor”), but 
in rather different ways. For the rollback 
relation, the current snapshot state is used; 
for the historical relation, the tuples cur¬ 
rently valid are searched; and for the tem¬ 
poral relation, the tuples currently valid in 
the current historical state are searched. 
The defaults defined in TQuel ensure that 
queries containing only where clauses will 
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Figure 8. Merrie is promoted to full professor. 


return the same information regardless of 
relation types. 7 

Merrie is promoted to full professor. In 

December of that year, a replace statement 
is executed: 

replace f (Rank = "Full Professor") 
where f.Name = "Merrie" 

Figure 8 illustrates the changes in the four 
relations. Since the snapshot relation 
records only the current information, the 
existing tuple is modified, as is the next 
payroll check made out to Merrie. A new 
snapshot state is appended to the rollback 
relation; Merrie’s pay stubs for September 
1973 through November 1973 still read 
“Instructor Merrie,” but the December 
1973 paycheck is made out to “Full Pro¬ 
fessor Merrie.” Snapshot states within the 
rollback relation are separated by dotted 
lines. A tuple is added to the historical 
relation with a valid time of December 
1973; an entry is also added to Merrie’s re¬ 
sume. The historical relation always con¬ 
tains only one historical state, so no dotted 
lines will appear in its illustration. 

The historical relation is an interval rela¬ 
tion. In the representation shown in Figure 
8, a tuple is valid until the next tuple with 
the same key becomes effective. Hence, 
the historical relation in this figure indi¬ 
cates that Merrie was an instructor from 
September 1973 until December 1973, 
when she became a full professor. The 
temporal relation contains two historical 
states: one current from September 
through November 1973 and the longer 
one created in December 1973. Merrie’s 
resume file now contains two resumes, one 
dated September 1973 containing one job 
position, and the more recent one dated 
December 1973 containing two job posi¬ 
tions. Only one transaction time is needed 
for each historical state, even if it contains 
multiple tuples. 

When we ask the next month, January 
1974, about Merrie’s rank, 

retrieve (f.Rank) 
where f.Name = "Merrie" 
we again get the same result from all four 
relations (“Full Professor”), except that 
we also get the past rank of Instructor 
from the historical and the temporal rela¬ 
tions. If we ask in January, “What was 
Merrie’s rank last October ?”: 

retrieve (f. Rank) 

where f.Name = "Merrie" 
when f overlap "October, 1973" 

we run into some difficulties. This query 
cannot be executed on a snapshot relation, 
since information about the past is not 


stored (looking at Merrie’s pay stub from 
January won’t tell us what the paycheck 
read three months earlier). The rollback 
relation can’t give us an answer either. Of 
course, we could flip through the payroll 
stubs, but such a search won’t tell us if 
Merrie was given a retroactive promotion 
(such a situation will be examined shortly). 
Both the historical and temporal relations 
can provide the answer “Instructor” by 
examining the current resume (the histori¬ 
cal relation records only the current one 
anyway). 

Still interacting with the DBMS in Jan¬ 
uary 1974, we ask “What did we think 
Merrie’s current rank was three months 
ago?”: 


retrieve (f.Rank) 
where f.Name = "Merrie" 
as of "October, 1973" 

This query effectively turns back the clock 
to October; all changes after October are 
not considered. A result is not forthcom¬ 
ing from either the snapshot or the histori¬ 
cal relations, because they both record 
only current knowledge (in the case of 
historical relations, current knowledge 
about the past). In this case, however, flip¬ 
ping through the pay stubs or the stack of 
resumes (the rollback and temporal rela¬ 
tions, respectively) will allow us to deter¬ 
mine what we knew in October 1973: that 
Merrie was then an instructor. 


September 1986 


39 


























Snapshot: 


Rark . 


Merrie 

Assistant Professor 


Rollback: 


Rark 

(Transaction Time) 


Merrie 

Instructor 

(September 1973) 


Merrie 

Full Professor 

(December 1973) 


Merrie 

Assistant Professor 

(February 1974) 

Historical: 

(Valid Time) 

Name 

Rark 


(September 1973) 

(December 1973) 

Merrie 

Merrie 

Instructor 

Assistant Professor 


Temporal: 

(Valid Time) 

Name 

Rark 

(Transaction Time) 

(September 1973) 

Merrie 

Instructor 

(September 1973) 

(September 1973) 
(December 1973) 

Merrie 

Merrie 

Instructor 

Full Professor 

(December 1973) 

(September 1973) 
(December 1973) 

Merrie 

Merrie 

Instructor 

Assistant Professor 

(February 1974) 


Figure 9. A correction. 


A correction. In the next month, 
however, we realize that we made a mis¬ 
take. Last December, Merrie wasn’t pro¬ 
moted from instructor to full professor; 
she was only promoted to assistant pro¬ 
fessor. We modify the historical and the 
temporal relations in February 1984 by 
replace f (Rank = * Assistant Professor ") 
valid from begin of "December 1973" 
where f.Name = "Merrie" 
but we can correct only the current state of 
the snapshot and rollback relations by 
replace f (Rank = " Assistant Professor") 
where f.Name = "Merrie" 

Figure 9 shows that the next paycheck will 
indicate a new rank, paychecks issued 
from February 1974 on will bear the cor¬ 
rect title, and the current resume is cor¬ 
rected. 

Note that the pay stubs for December 
1973 and January 1974 still mention “Full 
Professor Merrie” and that the resume file 
still contains an old resume with the incor¬ 
rect promotion rank; both of these rela¬ 
tions are by definition append-only. 

We perform three queries in August. 
We first ask about Merrie’s current rank: 
retrieve (f.Rank) 

where f.Name = "Merrie" 

All four relations respond with “Assistant 
Professor,” except that we also get the 
past rank of “Instructor” from the 


historical and temporal relations. When 
asked what Merrie’s rank was in January, 

retrieve (f.Rank) 

where f.Name = "Merrie" 
when f overlap "January 1974" 
the snapshot and rollback relations cannot 
provide an answer. However, the histori¬ 
cal and temporal relations both respond 
with the corrected rank, “Assistant Pro¬ 
fessor.” 

If we ask a different question, “What 
was Merrie’s current rank as best known 
last January?”, 
retrieve (f.Rank) 

where f.Name = "Merrie" 
as of "January 1974" 

then the snapshot and historical relations 
cannot reply, since they only record infor¬ 
mation as currently known. Both the roll¬ 
back and temporal relations can provide 
the information we request (“Full Profes¬ 
sor”), while the temporal relation also 
provides the past rank of “Instructor.” 

Merrie is promoted retroactively. In 

December 1978, Merrie is promoted to 
associate professor, retroactive from June 
1978. We record the fact in the historical 
and temporal relations by 

replace f (Rank = " Associate Professor ") 
valid from begin of "June 1978" 
where f.Name = "Merrie" 


but we can modify only the current state of 
the snapshot and rollback relations by 

replace f (Rank = " Associate Professor") 
where f.Name = "Merrie" 

As shown in Figure 10, the fact that the 
promotion was retroactive is irrelevant in 
the snapshot and rollback relations. In 
particular, the pay stubs (the rollback rela¬ 
tion) from February 1974 to November 
1978 still specify “Assistant Professor 
Merrie.” However, the current resume 
(the historical relation) and the most re¬ 
cent resume in the resume file (the tem¬ 
poral relation) will both record the promo¬ 
tion date as June 1978. 

When we query the relations in the fol¬ 
lowing March, all four will list Merrie’s 
current rank as “Associate Professor.” 
The historical and temporal relations Will 
list her rank in October 1978 as “Associate 
Professor.” The rollback and temporal re¬ 
lations will list her current rank, as best 
known in October 1978, as “Assistant Pro¬ 
fessor,” indicating that the promotion had 
not been made. However, the temporal 
relation can answer even more involved 
queries, such as “What was Merrie’s rank 
in October 1978, as best known in 
November 1978?”: 

retrieve (f.Rank) 

when f overlap "October, 1978" 
where f.Name = "Merrie" 
as of "November 1978" 

This query can only be answered by the 
temporal relation, which returns a rank of 
“Assistant Professor.” If the as of clause 
were omitted, the result would be “Asso¬ 
ciate Professor.” 

We have examined the information rep¬ 
resented by each of the four types of rela¬ 
tions and have shown how each relation 
responds to various update and retrieval 
operations. A few tautologies should now 
be defensible: 

• The most recent snapshot state in the 
rollback relation is always identical to 
the entire contents of the snapshot 
relation. 

• Similarly, the most recent historical 
state in the temporal relation is 
always identical to the entire contents 
of the historical relation. 

• Queries containing only a target list 
and a where clause will return the 
same information when applied to 
any of the four types of relations. 

An implementation 

There are several approaches to imple¬ 
menting a DBMS supporting the opera- 
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Figure 10. Merrie is promoted retroactively. 


tions described above. When confronted 
with the task of adding temporal support 
to a DBMS, one reasonable initial strategy 
would be to interpose a layer of code be¬ 
tween the user and the database system. 
This layered approach has the significant 
advantage of not requiring any change to 
the complex data structures and algo¬ 
rithms within the DBMS proper. How¬ 
ever, the performance of such a system 
may be inadequate. An immediate con¬ 
cern is the monotonically increasing and 
potentially enormous storage require¬ 
ments. In addition, there are multiple ver¬ 
sions for some tuples, rendering conven¬ 
tional storage schemes such as indexing or 
hashing less effective. Performance will 
deteriorate rapidly not only for temporal 
queries but also for nontemporal queries. 

An alternative is to integrate temporal 
support into the DBMS itself, developing 
new query evaluation algorithms and ac¬ 
cess methods to achieve reasonable perfor¬ 
mance for a variety of temporal queries 
without penalizing more frequent non¬ 
temporal queries. This approach clearly 
involves substantial research and imple¬ 
mentation effort, yet promises to address 
deficiencies in performance. 

We have adopted an intermediate strat¬ 
egy in implementing our prototype tem¬ 
poral DMBS. We modified portions of the 
snapshot DBMS Ingres, 6 but still used the 
conventional access methods and query 
evaluation algorithms available in it. Such 
a strategy may also be useful when adding 
temporal support to a conventional hierar¬ 
chical or network DBMS. This prototype 
helps identify problems with conventional 
access methods and query evaluation al¬ 
gorithms in providing temporal support, 
and serves as a comparison point for fully 
integrated DBMSs developed in the 
future. We also used it to run the example 
queries above, where it flagged a few sub¬ 
tle errors that had escaped our scrutiny. 

One of the most important decisions 
was determining how to embed a four¬ 
dimensional temporal relation into a two- 
dimensional snapshot relation as sup¬ 
ported by Ingres. There are at least five 
ways to embed a temporal relation in a 
snapshot relation. 7 Our prototype adopted 
the scheme of augmenting each tuple with 
two transaction time attributes for a roll¬ 
back and a temporal relation, and one or 
two valid time attributes for a historical 
and a temporal relation, depending on 
whether the relation modeled events of in¬ 
tervals. Each update operation on an exist¬ 
ing tuple generates a new version of the 
tuple, marked with appropriate values of 


time attributes indicating the period the 
version is active. Although this tuple ver¬ 
sioning scheme appears to have a high 
degree of redundancy, in that the entire 
tuple is duplicated whenever the value of 
any attribute changes, analysis reveals that 
this scheme consumes less space than at¬ 
tribute versioning when the database is not 
volatile. 8 

For the prototype, the parser of Ingres 
was modified to accept TQuel statements 
and generate an extended syntax tree with 
subtrees for valid, when, and as of clauses. 
Some of the query evaluation modules 
were changed to handle the newly defined 
node types and the implicit temporal at¬ 
tributes. Functions to handle the temporal 
operators begin of, end of, precede, over¬ 
lap, extend, and as of were added in the in¬ 
terpreter. The system relation was modi¬ 
fied to support the various combinations 
of implicit temporal attributes according 
to the type of relation as specified by its 
create statement, an example of which ap¬ 
peared earlier. The temporal attribute has 
a distinct type, so that input and output of 


time values can be done in human readable 
form by automatically converting to and 
from the internal representation. Various 
formats of date or time are accepted for in¬ 
put, and resolutions ranging from second 
to year are selectable for output. The copy 
statement was also modified to support 
batch input and output of relations having 
temporal attributes. 

The resulting prototype supports all the 
TQuel statements, including the aug¬ 
mented create, append, delete, replace, 
and retrieve statements. The valid, when, 
and as of clauses are fully supported. All 
three kinds of time are supported, as are all 
four types of relations. Proposed exten¬ 
sions to the language, including indeter¬ 
minacy and aggregate functions, are not 
yet supported. 

To evaluate the performance of the 
prototype, we ran a benchmark with a set 
of queries on the four types of databases 
using various access methods. We deter¬ 
mined the fixed portion, the variable por¬ 
tion, and the growth rate of the disk access 
cost for various types of queries, as the 
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number of versions in each database in¬ 
creased using a series of replace opera¬ 
tions. 9 Performance degraded rapidly for 
both temporal and nontemporal queries, 
as expected for conventional access 
methods such as hashing and indexed se¬ 
quential access. We are investigating new 
access methods addressing this problem to 
enhance the performance. 

W hile fifteen years of research 
have focused on formalizing 
and implementing snapshot 
databases, only a few researchers have 
recently studied the formalization of 
historical databases and the implementa¬ 
tion of rollback databases. Little has been 
published on formalizing rollback or tem¬ 
poral databases, or on implementing his¬ 
torical or temporal databases. The special 
opportunities promised by temporal 
databases are, at this time, matched by the 
challenges in supporting them. 
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A message-based 
multiprocessor can 
yield linear or better 
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M ultiprocessor computers have 
been commercially available for 
over 20 years in a variety of 
forms. Typically, loosely coupled systems 
provide good throughput at the expense of 
flexible resource sharing, while tightly 
coupled systems provide flexible resource 
sharing at the cost of degraded through¬ 
put. Most tightly coupled multiprocessor 
systems degrade markedly when the num¬ 
ber of CPUs reaches three or four. That is, 
for each additional CPU, the system per¬ 
formance improves by some fraction of 
the original CPU (usually 0.8-0.9 for the 
second one), and that fraction decreases as 
the number of CPUs increases. 

The reasons for the less than linear per¬ 
formance improvement of typical multi¬ 
processors include contention for re¬ 
sources, both hardware and software. 
Typically, multiprocessors encounter con¬ 
tention at memory units and the paths that 
are used to access them. Interprocessor 
communication is also a source of degra¬ 
dation as processors communicate with 
one another in order to keep common- 
state information current. Contention for 
software resources is most often in the 
form of critical sections protected by spin 
locks, where one processor at a time can 
hold a lock, and all others trying to gain 
the lock must wait in a loop. 

The measurements that are reported 
here were performed in order to charac¬ 
terize the performance of a tightly coupled 
multiprocessor, the Elxsi 6400, through- 

0018-9162/86/09000047S01.00 © 1986 IEEE 


out the range of 1 to 10 CPUs, which was 
the implementation limit at the time. This 
system has a message-based architecture 
with several design features intended to 
enhance multiprocessor performance with 
the goal of achieving linear performance 
improvement as CPUs are added. This set 
of experiments was intended to answer the 
question of whether or not this type of sys¬ 
tem could achieve, or possibly exceed, 
linear performance improvement. Con¬ 
figuration details of the Elxsi 6400 are 
shown in the sidebar (following page). 

Performance measures 

The usual method of measuring CPU 
power is in terms of throughput, usually 
millions of instructions per second, or 
MIPS. When measuring a multiprocessor, 
a ratio is more convenient. That is, a sys¬ 
tem with n processors yields x times the 
throughput of a system with m processors. 

However, there is an issue of how the 
throughput should be computed. There 
are two methods that are used here: system 
throughput and CPU throughput capaci¬ 
ty. Of the two, CPU throughput capacity 
is the more accurate measure of the CPU 
performance of the system, while the sys¬ 
tem throughput is a measure of the overall 
performance of the system. 

System throughput. When measuring a 
particular workload on a variety of 
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Rab = (X/B a )/(X/B b ) 
= B b /B a 


dissimilar computers, using a ratio of the 
system throughput is appropriate as the 
measure requiring the least amount of 
justification. The system throughput ratio 
of system a to system b is defined as 
R ab = Throughput,,/throughput b 
= (X/T a )/(X/T b ) 

= T b /T a 

where A'= Total work 

T a = Elapsed time of system a 
In some cases, this is the only relevant 
measure of two systems. However, when 
only CPU power is being compared, it is 
not accurate if the workload is not com¬ 


pletely compute-bound. This is because, 
as the computational power increases, the 
non-CPU related components of the 
workload occupy a larger fraction of the 
total elapsed time, penalizing the system 
with more processing power. 

CPU throughput capacity. A better 
measure of relative CPU performance is 
CPU throughput capacity. CPU through¬ 
put capacity is simply the maximum ser¬ 
vice rate that the CPU(s) exhibited during 
the measured run, or the amount of work 
done per unit of CPU time. To compute a 
ratio of CPU throughput capacities, then, 


where B a = CPU busy time of system a 

For a multiprocessor, B is defined as the 
average CPU busy time, B = (2?j + B 2 + 

. . . + B„)/n. This definition of 
throughput makes sense for a multipro- 
grammed computer system, because for a 
given workload, any unused CPU cycles 
could presumably be used by some other 
processes doing useful work. For a deriva¬ 
tion of CPU throughput capacity, see the 
sidebar. 


Elxsi 6400 system features 


The ELXSI 6400 is built around a cen¬ 
tral bus. The central processors are made 
of custom ECL gate arrays and can exe¬ 
cute over 7 million Whetstone instruc¬ 
tions per second. I/O processors use the 
same hardware as central processors, 
with different microcode and a special 
I/O controller interface. 

System bus 
64 bits wide 
25-ns cycle time 
320 M-byte/s raw bandwidth 
213 M-byte/s usable bandwidth 

Memory 
8-768M bytes 

Central processors 
1-10 central processors 
64-bit word length and internal datapaths 
50-ns cycle time 
32-bit virtual address space 
150-ns, 64-bit floating point add time 
16 general-purpose register sets 
16K-byte, two-way set associative cache 

I/O processors 
1-4 I/O processors 

16 M-byte/s bandwidth per I/O processor 
32-device controllers per I/O processor 


CPU throughput 
capacity 

There are at least two different 
measures of throughput: throughput at 


the system level and throughput at the 
resource level. Figure A depicts the sys¬ 
tem as a queueing network, showing the 
two different measures of throughput. 
System throughput is defined as the 
number of jobs completed per unit of 
time. An individual resource’s throughput 
is defined as the number of service com¬ 
pletions at that resource per unit time. 
Note that the number of service comple¬ 
tions at any given resource is not 
necessarily the same as the number of 
job completions for the system. The ratio 
of service completions at a given re¬ 
source to job completions is often called 
the visit ratio for that resource. 

Because identical workloads are used, 
a system throughput ratio is simply the 
ratio of elapsed times. When dealing with 
workloads that exercise more than one 
resource in the system, like most 
realistic workloads do, system through¬ 


put will not accurately reflect the perfor¬ 
mance difference of a given resource. In 
other words, a system throughput ratio 
will not tell you how much faster this 
new processor is than the old one. 

If the point of the measurement experi¬ 
ment is to characterize the performance 
of a given resource, then throughput of 
that resource is a more appropriate 
measure. However, the throughput at the 
resource alone is not adequate, since it 
is determined by the total time the work¬ 
load takes. What is ultimately needed is 
a measure of the rate at which requests 
can be serviced at that resource. Since 
the concern here with the processor(s) as 
a resource, the term “processor through¬ 
put capacity” will be used as a measure 
of maximum processor service rate. 

The following notation and definitions 
will be used. These come from the “fun- 



Figure A. System throughput= J/T. 
















Workloads 

The workloads selected for measure¬ 
ment were put together in order to satisfy 
several criteria, including convenience. 
They are all noninteractive, due to lack of 
facilities for terminal emulation. The 
workloads contain real programs, in¬ 
cluding significant Fortran compilation 
components. 

The workloads used in these experi¬ 
ments were multiple job workloads, as 
might be found in a general-purpose scien¬ 
tific programming shop. One workload 
was a fixed load and one was a progressive 


load. The fixed load was simply a collec¬ 
tion of jobs, all started at the same time, 
run identically on each configuration. The 
progressive load was a collection of jobs 
made up of a variable number of basic job 
sets. The idea was to run as many job sets 
as there were CPUs in the configuration, 
keeping the load per CPU constant. 

A fixed load. This workload consisted 
of 60 jobs, each run from a shell (com¬ 
mand) file. The job mix included Fortran 
compiles, sequential programs, and paral¬ 
lel programs. The Fortran compiles used 
the standard Fortran compiler to compile 


several different Fortran programs of 
moderate size. 

The sequential programs were actual 
application Fortran programs and were 
used because they were relatively short (80 
and 25 seconds of CPU time) and did very 
little I/O. These were important con¬ 
siderations for constructing a workload 
that would run in a reasonable amount of 
time on both a 1-CPU system and a 
10-CPU system. 

The parallel programs were demonstra¬ 
tion programs, one using 10 subtasks and 
the other using 5 subtasks. The subtasks 
could run concurrently on different 


damental laws” of operational perfor¬ 
mance analysis given in reference 8. 

T = Length of the measurement 
interval 

J = Number of jobs completed during 
the measurement interval 

X = Throughput, or number of jobs 
completed per unit time, or 
X=J/r 

B = Amount of time that the 

processor resource is busy during 
the measurement interval 

U = Utilization of the processor 
resource; u- B/T 

C = Total number of service requests 
completed by the processor 

S = Average service time for a request 
at the processor; S= B/c 

Subscript a is used to qualify a 
variable by the configuration—for exam¬ 


ple, X a will mean the throughput of sys¬ 
tem a. 

In essence, throughput capacity, or TC, 
for a resource is simply the maximum 
service rate that the resource can reach. 
This service rate can be obtained from 
measured quantities by 

TC = 1/S 
= C/B 

The throughput capacity ratio between 
systems a and b can then be expressed 
as 

R a , b = S b /S a 

= (C a /B a )(B b /C b ) 

= B b /B a 

This says that in* throughput capacity 
of the processor In configuration a is 
R ab times the throughput capacity of the 
processor in configuration b. 


For a multiprocessor, the basic quan¬ 
tities are slightly different, and the 
derivation requires an assumption about 
the nature of the multiprocessor. See 
Figure B. Because the processor is a 
multiserver, the busy time is now the 
sum of the individual processor’s busy 
times, yielding a processor utilization 
that can be as large as nT: 

C = c,+ c 2 + ... + c n 
B = b, + b 2 + ... +B n 

U = B/T 
S = B/C 


If it is assumed that the processors 
are symmetric and identical, and that the 
workload is uniformly distributed across 
the processors, then for a sufficiently 
large workload, e, = By = B/n. That is, 
no one processor will do any more work, 
or any less, than any other. This is a 
reasonable assumption in a tightly cou¬ 
pled, symmetric multiprocessor, since 
processors are typically assigned to in¬ 
coming work as they are available. The 
processor service rate, or processor 
throughput capacity, is now given by 
TC = n/S 


Therefore, the processor throughput 
capacity ratio of two multiprocessors a 
and b, with n and m processors, respec¬ 
tively, is given by 


R a,b = (n/S a )/(m/S b ) 

~ (nC a /B a )- (B b /(mC b )) 
= (nB b )/(mB a ) 






















CPUs, if there were enough CPUs avail- 

Table 1. Fixed workload composition. able. These programs were completely 

CPU bound. 

Table 1 shows the memory sizes, CPU 
time requirements, and proportions of the 
jobs in the fixed workload mix. The CPU 
percentages indicate how much of the total 
CPU time was consumed by each type of 
job, along with the operating system, 
when run on a 1-CPU system. 

The I/O activity of this workload is 
quite low, reaching a maximum of only 30 
disk transactions per second. This was 
purposely kept low on account of the 
limited I/O equipment available for the 
measurements. 

A progressive load. The progressive 
load was composed of a variable number 
of copies of a basic set of jobs. The jobs 
were selected from the fixed workload. 
This set of jobs was replicated as many 
times as there were CPUs in the configura¬ 
tion. Thus, if the load imposed by the 
basic set of jobs is B, then the workload 
for a configuration with n CPUs is nB. 
The characteristics of the basic set when 
run on a 1 -CPU system is given in Table 2. 


Results 

The measurements were made on an 
Elxsi 6400 multiprocessor. The Elxsi 6400 
can be described as a bus-oriented sym¬ 
metric multiprocessor with single pro¬ 
cessor performance in the supermini class. 
The architecture has been described in 
references 1 and 2. See Figure 1 for a pic¬ 
ture of the system organization. 

The different workloads were run on 
configurations that had 1 to 10 CPUs and 



Figure 1. Elxsi 6400 system organization. 


Function Size CPU time No. of jobs % CPU 


Fortran compile 

1. 2124-line, 30-subroutine program 

2.QM bytes 

83 s 

6 

12 

2. 423-line, 3-subroutine program 

2.0M bytes 

28 s 

6 

4 

3. 1143-line program 

1.6M bytes 

30 s 

6 

4 

4. 676-line program 

2.6M bytes 

41 S 

12 

11 

Sequential execution 

1. Source program analyzer 

280K bytes 

25 s 

6 


2. 3-D gravitational anomaly computa- 

tion 

200K bytes 

81 s 

12 

23 

Parallel execution 

1. Five-function benchmark program 

8Q0K bytes 

110s 

6 

15 

2. Matrix multiply done with 10 

parallel subtasks 

Operating system 

10.OM bytes 
4.0M bytes 

26 s 

6 

23 


Table 2. Progressive workload basic job set composition. 



Table 3. Fixed workload results. 


No. Of CPUs 


2 

4 

5 

6 

8 

9 

10 

Elapsed time 

4292 

1974 

984 

778 

658 

499 

443 

405 

Total CPU time 

3871 

3689 

3667 

3636 

3632 

3616 

3591 

3581 

CPU time/CPU 

3871 

1845 

917 

727 

605 

452 

399 

358 

Kernel % of available CPU time 

10.9% 

8.6% 

8.0% 

7.4% 

7.1% 

6.5% 

6.2% 

6.1% 

Throughput ratio 

1.00 

2.17 

4.36 

5.52 

6.52 

8.59 

9.69 

10.61 

CPU throughput capacity ratio 

1.00 

2.10 

4.22 

5.32 

6.39 

8.56 

9.70 

10.81 
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memory configurations of 96 and 64M 
bytes. The I/O configuration was minimal 
for a system of this computational power, 
consisting of just four 400M-byte disk 
drives on two disk controllers. To obtain 
configurations with fewer CPUs, the ap¬ 
propriate number were configured in 
before bringing the system up. Memory 
and I/O configurations remained identical 
for any set of measurements. 

The data reported here was obtained by 
means of a software monitor that samples 
various system-maintained counters at ap¬ 
propriate intervals. There are some arti¬ 
facts due to measurement, but they are 
minor. 

Fixed load results. The fixed workload 
was run in a system with 96M bytes of 
memory, four disk drives, two disk con¬ 
trollers, and 1 to 10 CPUs. Table 3 gives 
the results for the fixed workload. 

This workload was put together in such 
a way that all jobs to be executed would be 
started at the beginning, and many of 
them would end at about the same time. 
By doing this, the start-up transient before 
the system reached a steady state was quite 
short, and, more importantly, the ending 
transient was also relatively short. The 
lengths of these two periods of the 
measurement interval have a pronounced 
effect on the system throughput ratios 
given here, but little effect on the CPU 
throughput capacity ratios. 

The measurement funs in this set of 
measurements were all replicated, and the 
values given are averages. The run-to-run 
variation of this workload was very small. 
The largest variation in elapsed time, 
which is usually the most volatile, was 2 
percent. The largest variation in total CPU 
time was less than 1 percent. 

The notable results of this set of 
measurements are the two throughput 
ratios. The throughput ratios are plotted 
in Figure 2. Both throughput ratios actual¬ 
ly increased more than linearly for this 
workload. A 10-CPU Elxsi 6400 can do 
more than 10 times the work of a 1-CPU 
Elxsi 6400. The reasons for this surprising 
result can be found in the percent of CPU 
time used by the operating system kernel. 
The CPU time for each individual process 
in the workload remains constant across 
configurations, but the times for kernel 
processes do not. As CPUs are added to 
the system, the kernel becomes more effi¬ 
cient. In addition, although the amount of 
work it does servicing paging and file I/O 
remains relatively constant, the amount of 
work it must do to schedule processes 



Number of CPUs 


Figure 2. Fixed workload throughput ratios. 


Table 4. Progressive workload results. 
No. of CPUs 1 

Elapsed time 283 

Total CPU time 265 

CPU time/CPU 265 

Kernel % of available CPU time 11.8% 

Throughput ratio 1.00 

CPU throughput capacity ratio 1.00 


within processors actually decreases. The 
section Operating System Overhead below 
further discusses this effect. 

Perhaps the most surprising result is 
that the overall system throughput in¬ 
creased more than linearly with CPUs, 
tracking the CPU throughput capacity. 
This is primarily because this workload 
was compute-bound for all configura¬ 
tions, and the transient periods of the 
workload were kept short. 

Progressive load results. The pro¬ 
gressive workload was run on a configura¬ 
tion of 64M bytes of memory, two disks, 
one disk controller, and one to eight 
CPUs. Table 4 gives the results for the pro¬ 
gressive workload. 

The progressive workload was com¬ 
posed of a variable number of identical 
units, each unit consisting of several dif¬ 
ferent jobs. By running as many units as 
there are CPUs in the configuration, 
throughput ratios can be calculated. The 
purpose of running this workload was to 
see if the results discussed in the section 


Fixed Load Results were due to reducing 
the amount of work done on each CPU. 
As in the fixed workload, an effort was 
made to keep the transient periods of the 
measurement interval as short as possible 
so that system throughput could be mean¬ 
ingfully compared. For this workload, 
I/O was more of a problem than it was 
with the fixed load because of the smaller 
disk configuration. In fact, a disk bottle¬ 
neck was reached by the time the workload 
had increased to eight units, so the system 
throughput ratio suffers at that point. 
Again, the CPU throughput capacity ratio 
remains unaffected. 

As in the fixed workload case, all runs 
were replicated, and the values given here 
are averages. In this workload, run-to-run 
variation was somewhat greater, with the 
maximum elapsed time variation being 10 
percent and the maximum CPU time vari¬ 
ation being 3 percent. 

The results, as shown in Table 4, con¬ 
firm that throughput still increases more 
than linearly as CPUs are added. Again, 
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Figure 3. Progressive workload throughput ratios. 


this is mainly attributable to the increased 
efficiency of the kernel as the configura¬ 
tion gets bigger. Figure 3 shows the two 
throughput ratios for this workload. 

Explanation of results 

In this section is a discussion of the rela¬ 
tionship between the system architecture 
and the benchmark results. The principal 
architectural feature of the Elxsi 6400 is 
that it is a message-based machine. The in¬ 
struction set includes a rich set of message 
handling primitives (implemented mostly 
in microcode). This architecture supports 
a global view of independent sequential 
processes that communicate with each 
other only by sending and receiving 
messages. In fact, this view is carried out 
to the point that instructions that manipu¬ 
late the state of the hardware are not in¬ 
cluded, those functions being entirely pro¬ 
vided by messages that processes send to 
special hardware processes. 

The results of these measurements show 
that, at least for the workloads in ques¬ 
tion, CPU throughput capacity increases 
linearly or better as CPUs are added. For 
the fixed workload, a 10-CPU machine 
has 10.8 times the CPU throughput capac¬ 
ity of a 1-CPU machine. This is quite a 
surprising result. For linearity to be 
achieved, there must be no effective con¬ 
tention for system resources (i.e., bus, 


memory, and critical regions). For greater 
than linear performance, the 10-CPU 
machine must either do less work or it 
must do the same work faster. In fact, both 
of these seem to be the case. 

Hardware contention. The primary 
physical characteristic of the machine is 
that it is built around a fast bus, called the 
Gigabus because its raw bandwidth is over 
1G bits/s, or 320M bytes/s. It has been 
postulated 3 that a bus architecture will 
not provide adequate performance in a 
general multiprocessor, because of conten¬ 
tion between all the active units on the bus 
attempting to access memory. The high 
speed of the Gigabus was intended to 
reduce bus contention to negligible levels 
in a multiprocessor environment. 

Because each active unit (CPU and I/O 
processor) has a writeback cache, bus traf¬ 
fic to memory is not high. In fact, hard¬ 
ware monitoring equipment attached to 
the bus during these measurements 
showed a maximum bus utilization of 20 
percent, with average values of 10 percent 
with 10 CPUs in the system. The bus retry 
rate, which is the measure of bus conten¬ 
tion, was never more than 1 percent, and 
was normally virtually zero. 

The low bus utilization is due to a low 
arrival rate of bus requests, which in turn 
is due to a high hit ratio in the caches. In 
fact, the cache hit ratio for the workload 
programs averaged 96 percent. The hit 
ratio for the operating system component 


of the workload was lower, however, as 
discussed in the section Operating System 
Overhead below. Cache effects can be the 
primary cause of degradation, or lack of 
it, in a multiprocessor configuration. If 
each CPU’s cache had a 100 percent hit 
ratio, then the only other factor that 
would degrade performance would be in¬ 
terprocessor communication, which could 
be a second-order effect, depending on the 
workload. However, when the hit ratio is 
less than 100 percent, even a small change 
can have a large impact on the associated 
CPU, and thus change the aggregate per¬ 
formance of the multiprocessor. 

The presence of caches on the active 
units reduces the bus and memory traffic, 
but it presents the stale data problem in a 
multiple-cache system. This problem is 
solved by the global view of the system. 
That is, processes interact by sending 
messages, not by sharing data. Thus, pro¬ 
cesses can share read-only code or data, 
but cannot share any data that may be 
modified without explicitly coordinating 
multiple processor accesses by using 
special system services. 

Therefore, each cache need not be 
aware of the contents of any other cache, 
so no special data paths between caches 
are required, and no bus-following logic is 
required on the caches. The same is true 
for translation lookaside buffers for vir¬ 
tual address translation. This obviously 
reduces the complexity of the cache im¬ 
plementation, and more importantly for 
performance purposes, imposes no addi¬ 
tional cache access or cache miss penalty 
for a multiprocessor environment. 

There are occasions, of course, when 
data that is in one cache must be flushed 
back to main memory, for example before 
initiating a disk write operation. For these 
occasions, an explicit flush cache opera¬ 
tion must be performed, but these are very 
infrequent compared to the normal cache 
operations. 

Contention for a memory port is 
negligible with these workloads. There are 
two ports per memory controller with two- 
way interleaving per controller. Conten¬ 
tion for the same memory location is not a 
problem in this system because modifiable 
memory is not normally shared. 

Software contention. Just as there is no 
contention for a physical memory location 
because of the operating system organiza¬ 
tion, there is no contention for critical 
sections. Process synchronization is 
managed by means of the message opera¬ 
tions. If a process does a receive opera- 
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Number of CPUs 

Figure 4. Normalized kernel time. 


Table 5. Memory manager CPU usage. 


No. of CPUs 1 2 4 

6 8 10 


tion and there is no message available, it 
becomes blocked. When a message sub¬ 
sequently is sent to that process, it be¬ 
comes unblocked. All such process syn¬ 
chronization is done within the microcode 
of the message operations. As a result, 
there are no spin locks in the operating 
system. 

This is especially important in the CPU 
dispatching function. Typically, in tightly 
coupled multiprocessors, the dispatcher is 
a critical region because it manipulates a 
shared CPU queue. Since the operating 
system spends a nontrivial amount of time 
dispatching processors, the dispatcher 
critical region usually accounts for a 
significant amount of contention. In the 
Elxsi 6400, the dispatching function is dis¬ 
tributed to each CPU. 

Each CPU has 16 register sets, 15 of 
which contain the context of a process. 
These register sets are used by the micro¬ 
code to select the next process for that 
CPU to run. Thus, each CPU does its own 
dispatching, selecting from its own queue. 
There is an associated ready list of pro¬ 
cesses that is managed by an operating sys¬ 
tem process for each CPU. That process 
moves processes in and out of the CPU’s 
register sets. 

As a result of this organization, a pro¬ 
cess is bound to a single CPU until ex¬ 
plicitly moved. The cost of this is that 
load-levelling must be done explicitly. 
The advantage, however, is that there is 
no critical region, and therefore no con¬ 
tention. 

It should be noted here that software 
contention is indeed possible, given a 
workload that makes excessive demands 
upon a particular system process. As the 
arrival rate of service request messages ex¬ 
ceeds the rate at which a server process can 
complete service, that process becomes a 
bottleneck. In general, software bottle¬ 
necks do not occur very often, and did not 
occur in these workloads. 

Operating system overhead. Given that 
resource contention is negligible, one 
would expect that CPU throughput would 
be a linear function of the number of 
CPUs. However, throughput increased at 
a greater than linear rate for these 
workloads. There are only two ways that 
can happen: either the system does less 
work, or it does the same amount of work 
faster. 

Results provided by the software 
monitor indicate that the user processes 
use the same amount of CPU time from 
one configuration to another. However, 


Fixed workload 

Elapsed time 4292 

Memory manager CPU time 405 

Memory manager % ot 1 CPU 9.4% 

Progressive workload 

Elapsed time 283 

Memory manager CPU time/CPU 29.1 

Memory manager % of 1 CPU 10,3% 


the kernel processes do not. The kernel 
process called the Memory Manager 
manages virtual memory and uses most of 
the kernel CPU time in these workloads 
(normal file I/O is handled with the same 
mechanism as page faulting, which is im¬ 
plemented in the Memory Manager). 
Operation counts show that page faults 
and disk I/O stay at relatively constant 
levels across configurations, but the time 
this process uses decreases as the number 
of CPUs increases. Figure 4 illustrates the 
overall kernel decrease in CPU time, nor¬ 
malized to the time it uses in the 1-CPU 
configuration for both workloads. 

Focusing on the Memory Manager, it 
typically is executed by only one CPU. As 
the arrival rate of work to the Memory 
Manager increases (that happens as CPUs 
are added), it consumes more and more of 
the CPU it resides on (see Table 5). The 


1974 984 658 500 405 

300 262 230 214 202 

15.2% 26.6% 35.0% 42.8% 49.9% 


266 271 289 300 

20.0 15.9 15.3 15.2 

15.0% 23.5% 31.8% 40.5% 


effect is that context switches on this CPU 
are reduced, and the time between Mem¬ 
ory Manager invocations is decreased. As 
a result, the Memory Manager’s context 
tends to stay in the cache from invocation 
to invocation, since there is less chance for 
some other process to execute and replace 
the data in the cache. As more of the 
Memory Manager’s context remains in 
cache between invocations, its cache hit 
ratio goes up, and it runs faster. 

Looking more closely at the Memory 
Manager CPU time, one can model the ef¬ 
fect of increasing the number of CPUs on 
the number of cache misses, which can 
then be related to the CPU time. To follow 
this line of reasoning, assume that the 
cache misses generated by some sequence 
of instructions is given by the stack growth 
function 4 

M = al b 
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where Mis the number of misses generated 
by I instructions, and a and b are con¬ 
stants. 

Now, our interest is in comparing the 
Memory Manager time from one con¬ 
figuration with the time from another. 
Since the amount of work the Memory 
Manager does is nearly constant between 
configurations, and thus the number of in¬ 
vocations are the same, the time between 
Memory Manager invocations is propor¬ 
tional to the elapsed time, which in turn is 
directly proportional to n, the number of 
CPUs in the configuration. Hence, the 
number of non-Memory Manager instruc¬ 
tions executed between Memory Manager 
invocations is given by 
/„ = /,/« 

where /] is the number of instructions exe¬ 
cuted between Memory Manager invoca¬ 
tions in a 1-CPU configuration. 

The number of misses generated be¬ 
tween Memory Manager invocations is the 
number of cache lines containing Memory 


Manager code and data that are displaced 
and will subsequently be missed on later 
Memory Manager execution. Therefore, 
the number of Memory Manager cache 
misses is given by an equation of the form 

and 

M n =a(I\/n) b 
= M x (\/n) b 
= M\/n b 

The overall Memory Manager execu¬ 
tion time is T = Tj + T M , where 77 is the 
actual instruction execution time, and T M 
is the time waiting for cache misses. 
Assume T, to be constant. Cache misses 
M„ can be turned into time T M by 
suitable adjustment of the constant a, 
yielding 


T n = T, + T Mn 
= T,+ T Mx /n b 


Figures 5 and 6 show a least squares fit 
of the Memory Manager CPU time as 
given in Table 5 for both workloads, using 
an equation of this form. The fitted curves 
match the observed values quite well, sup¬ 
porting this explanation. 

There is another effect of reducing con¬ 
text switching that results in the system 
doing less work as the configuration gets 
bigger, and that has to do with the register 
sets implemented in each CPU. In a 
1-CPU configuration there are 16 register 
sets, 14 of which can be used by workload 
processes. In a 10-CPU configuration 
there are 140 register sets for use by 
workload processes. If the number of pro¬ 
cesses in the workload stays constant, 
which it did in the fixed workload, then 
there will be less need to move processes in 
and out of register sets when processes are 
dispatched. This appears to be a notice¬ 
able effect—on the order of 3-5 percent of 
one CPU in the 1-CPU configuration, 
which drops to zero on the 10-CPU con¬ 
figuration. In the progressive workload, 
however, the additional register sets have 
no effect, since the number of processes 
per CPU remains constant. 

Cost of optimizing for multiprocessors. 

A possible criticism of the results here is 
that the 1-CPU configuration is artifi¬ 
cially slow, so subsequent ratios look arti¬ 
ficially high. There is some validity to this 
argument, in the sense that message opera¬ 
tions implemented in microcode are not 
free, and tend to be somewhat more ex¬ 
pensive than the comparable operations in 
a non-message-based uniprocessor en¬ 
vironment. See reference 2 for more infor¬ 
mation about the absolute cost of message 
operations. 

However, it is irrelevant how fast a 
uniprocessor could have been imple¬ 
mented using some alternate architecture. 
The absolute performance of the uni¬ 
processor is really only important in rela¬ 
tionship to its price. More to the point, 
even if some price is paid in uniprocessor 
performance, the ultimate gain in multi¬ 
processor performance will eventually 
make up for it. 


T he measurements presented here 
demonstrate that the Elxsi 6400 
exhibits essentially linear multi¬ 
processor performance. In a multipro- 
grammed workload, the CPU throughput 
capacity can be greater than linear. In fact, 
overall system throughput can also be 
greater than linear. 
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The results described here are iui 
essentially one workload, since the pro¬ 
gressive load is a variation of the fixed 
load. The existence of a workload that 
exhibits greater than linear speed-up is 
interesting, but a more important question 
is how general is this result. That is, are 
there any other such workloads, or is this 
the only one? Looking at the workload 
itself, it is unremarkable, other than the 
fact that it is composed of a relatively 
small number of different jobs, and it is 
CPU bound over a wide range of CPU 
power. One would expect that similar 
types of workloads would exhibit the same 
results. 

In fact, one other workload has been 
measured over the entire 1- to 10-CPU 
range. It is composed of a larger number 
of job types and does considerably more 
I/O. As would be expected, it shows less 
than linear speed-up of the throughput 
ratio when it hits a disk bottleneck. How¬ 
ever, the speed-up of the CPU throughput 
capacity is consistent with the results 
presented here. 

It is not clear at this point how much the 
message-based architecture of the machine 
contributes to its good multiprocessor per¬ 
formance, and how much is simply due to 
fortuitous implementation decisions (i.e., 
fast bus, adequate operating system 
distribution, etc.). In reference 5 a fairly 
convincing argument is given that proce¬ 
dure- and message-oriented operating sys¬ 
tems are duals of one another in terms of 
performance. While the results here do not 
directly address that issue, they do demon¬ 
strate that a message-oriented approach, 
when executed consistently from hard¬ 
ware through microcode to software, can 
exhibit “ideal” multiprocessor perfor¬ 
mance. See reference 6 for a description of 
another message-oriented system, and 
reference 7 for some comments about the 
performance of a procedure-oriented 
system. 

On the other hand, the effects seen here 
on the efficiency of kernel processes leads 
to speculation that the existence of a cache 
on each processor may favor the message- 
based architecture. 

These measurements have demon¬ 
strated that system overhead operations 
can become more efficient as the mul¬ 
tiprocessing level increases, and individual 
kernel processes become more cache-resi¬ 
dent. Experience with multiprocessors 
whose kernels use shared data shows that, 
typically, cache hit ratios go down as the 
multiprocessing level goes up. One can 
speculate that this is a significant perfor¬ 


mance difference between the two types of 
architecture. Similar results for a proce¬ 
dure-oriented system have not been pub¬ 
lished, to the author’s knowledge. □ 
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The Applied Imagery Pattern Recognition (AIPR) Subcommittee of the Pattern Analysis 
and Machine Intelligence Technical Committee, IEEE Computer Society, and the Night 
Vision and Electro-Optics Directorate, Fort Belvoir, will sponsor the Fifteenth Annual 
Workshop on Applied Imagery Pattern Recognition. The workshop will emphasize the 
practical uses of image pattern recognition and the need for expanded industry- 
govern ment-u nive rsity interaction. 

This year’s workshop will focus on Concurrent Processing for Vision. The processing of 
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years. Higher frame rates, resolutions and numbers of channels have combined with 
more computationally intensive algorithms to overwhelm traditional computer 
architectures. Concurrent processing technology offers enormous increases in 
processing power while introducing new tradeoffs and complexities that the image 
understanding and computer science communities are beginning to address in practical 
terms. Recent progress in both methodology and equipment, together with a growing 
urgency of the needs for this capability, makes this year’s theme particularly timely. 
Applications include industrial production, military reconnaissance, and natural 
resources management. It is the goal of this workshop to provide a forum for discussion 
of concurrent methods and their application to practical endeavors. 
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Washington’s embassies. Dupont Circle, the center of Washington’s night life, is two blocks away. An enormous variety of 
restaurants, from fast food to Washington’s best, as well as shops and night clubs, are in the Dupont Circle area. The Phillips 
Collection, one of Washington’s finest smaller art museums, is around the corner from the Club. 

We have arranged for a block of rooms at the nearby Dupont Plaza Hotel, and most of the city’s other hotels are only a short 
subway ride away. The club is a short two-block walk from the Dupont Circle Metro station. 
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A Complete and 
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of Covered Windows 


Brad A. Myers 
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The Sapphire window 
manager supports 
many important 
features, including 
flexible window 
refreshing, full- 
functionality 
subwindows, and 
optimized raster-op, 
that are not 
supported in most 
comparable systems. 
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S apphire, the Screen Allocation 
Package Providing Helpful Icons 
and Rectangular Environments, is 
a window manager 1 for the Accent 
operating system 2 running on the PERQ 
personal workstation. It has been used at 
Carnegie-Mellon University and by PERQ 
Systems Corp. and its customers. Like the 
window managers for many other person¬ 
al workstations and intelligent terminals, 
Sapphire supports the covered window 
paradigm, in which windows are rectangu¬ 
lar and can overlap arbitarily like pieces of 
paper on a desk (sometimes called the 
desktop metaphor). 

In this paradigm, a window may be on 
top of another window, just as one piece 
of paper may be on top of another piece of 
paper. The window that is behind is cov¬ 
ered by the window on top and the parts 
under the top window do not show through 
(see Figure 1). 

There is a total ordering imposed on all 
the windows where windows higher in the 
order cover windows that are lower. This 
is often called 2Vi dimensions, since the 
rectangles are thought to be layered in 
another dimension ( z ) pointing out of the 
screen. Windows that do not interact are 
still ordered. The top window is not 
covered by any windows. The window that 
is most covered is said to be on the bottom. 

The advantages of the covered window 
paradigm are that (1) there can be several 
large windows that would not all fit on the 
screen if they were required to be side by 
side, (2) the user can make more efficient 
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use of the screen, and (3) the metaphor is 
more familiar to users. The covered win¬ 
dow paradigm is used by a large number of 
existing window managers, 1,3_11 

The disadvantages are that it is more 
complex and expensive for the software, it 
is more difficult to provide programs that 
automatically manage windows, and users 
may waste time rearranging windows. 12 
Window managers that do not support 
covered windows only allow the windows 
to be side by side, often stacked in columns 
(these are called tiled window managers), 
and are growing in popularity. 13,14 

One of the major goals of Sapphire is to 
provide to users and application programs 
a wide range of functions so it would not 
unduly limit how application programs 
could use the screen or interact with users. 
The window size can be changed easily, 
and both characters and full bitmap 
graphic operations are supported. Sap¬ 
phire supports full covered windows, and, 
unlike some older window managers, lets 
windows be updated while they are cov¬ 
ered. Windows in Sapphire can also be 
partially or fully off the screen in any 
direction. 

It can also divide a window into subwin¬ 
dows. An application might provide dif¬ 
ferent areas for various types of displays 
while keeping them together in the same 
parent window so they can be manipulated 
as a unit. Sub windows also help the system 
and user organize the screen using 
context. 15 Subwindows can overlap and 
operate with full functionality. In fact, 
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Figure 1. A portion of an actual Sapphire screen. Window l V3 is covering window W2, 
and both windows W3and W2 are covering W1. W1 is on the bottom and W3 is on the 
top. W2 has a gray border to show that it is accepting user input (typing). The window 
in the lower part of the screen contains a number of icons showing process and win¬ 
dow state information. 1 


since top-level windows are actually sub¬ 
windows of the full screen window, all 
windows are subwindows. Other systems 
such as SunWindows 7 limit the func¬ 
tionality of subwindows. The user inter¬ 
face to Sapphire, which includes a novel 
use of icons, windows with title lines, pro¬ 
gress indicators, 16 and a simple but 
powerful user interface using the puck and 
keyboard, is described elsewhere. 1 

Like most other window managers, 
Sapphire is implemented entirely in soft¬ 
ware. A hardware implementation of the 
covered window paradigm exists, 4 but is 
probably too expensive to be practical in 
the near future. 


Background 

Sapphire runs on a raster (also called 
bitmap) display, which means that an area 
of memory holds the picture shown on the 
screen. Each point on the screen (pixel) 
corresponds to one bit in memory (so each 


pixel can be either white or black). For ex¬ 
ample, to set a spot on the screen to black, 
the corresponding bit in memory is set 
to 1. 

The primary method for doing graphics 
on the PERQ’s bitmap screen is the raster- 
op (sometimes called bitblt). 17 To avoid 
confusion this article uses “hardware 
raster-op” for the low-level function that 
actually moves bits, since it is implemented 
with special hardware on the PERQ. (The 
functionality of the hardware raster-op 
may actually be implemented by some 
combination of hardware, microcode, 
and software on other computers.) “Win¬ 
dow raster-op” refers to the high-level 
function that works with covered win¬ 
dows. 

Hardware raster-op moves an arbitrary 
bit rectangle from one part of memory to 
another. It also combines the source pic¬ 
ture with the destination picture using a 
number of different Boolean functions, 
such as AND, OR, XOR, and NOT. The 
source and destination rectangles may 


overlap arbitrarily or may even coincide. 
Since the screen bitmap is stored in main 
memory on the PERQ, the hardware 
raster-op can be used with both the screen 
memory and off-screen memory, and can 
perform transfers between the two. The 
hardware raster-op on the PERQ operates 
at full memory speed no matter what the 
bit orientations of the source and destina¬ 
tion rectangles are, so no special con¬ 
siderations need be made for the memory 
alignment used to hold bitmaps (as is done 
in Blit 5 ). 

Window raster-op can be used to imple¬ 
ment many other graphics operations. For 
example, to display text, a window raster- 
op is performed for each letter to move it 
from a font table (containing a picture for 
each character) to the appropriate place on 
the screen. In addition, window raster-op 
is used to implement changing a window’s 
size, position, and covering. 

Handling window 
refresh 

When a window is partially covered and 
then becomes uncovered, the parts that 
were previously hidden must be displayed. 
This can be the responsibility of the win¬ 
dow manager (and thus hide the need to 
refresh from the application) or it can be 
the responsibility of the application (and 
thus free the window manager from hav¬ 
ing to remember the picture). The method 
for handling refresh is the main distin¬ 
guishing difference among the implemen¬ 
tations of covered window managers. If it 
is the responsibility of the window man¬ 
ager, the window manager can save either 
the picture contained in the windows or 
the picture that the window covers (that 
are under the window). Interlisp-D 11 
saves the picture under every window, and 
Smalltalk 8 and others save the picture 
underneath for pop-up menus, but vir¬ 
tually all other systems—including Sap¬ 
phire—save the contents of windows in¬ 
stead. Saving contents and areas under¬ 
neath in the same window manager is very 
difficult. No matter how the window man¬ 
ager implements the saving internally, the 
procedure is hidden from programs using 
the windows. 

If the window manager saves the picture 
under a window, the full bitmap must be 
saved. However, if the contents of a win¬ 
dow are saved, there are several implemen¬ 
tation possibilities, including saving 

• the entire picture for each window in 
a separate off-screen buffer, 
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Figure 2. The rectangles that would be produced for window W1 in Figure 1 based on 
the windows W2 and W3. The rectangles marked V are visible, and those marked C 
are covered. 


• only the covered portions offscreen, 

• a general-purpose display list describ¬ 
ing what was displayed, and 

• combinations, such as bitmaps for 
pictures and characters for text. 

The first approach keeps a full shadow 
bitmap for every window in a separate 
off-screen buffer. Graphics operations 
are done to this buffer, and any visible 
portions are copied to the screen. This ap¬ 
proach is fairly simple to implement and 
very popular. It is used by Sun Windows. 7 
The main problem is that it takes a lot of 
extra memory to hold all the bitmaps, 
some of which is redundant, and it takes 
extra time for displaying because graph¬ 
ics in visible parts must be drawn twice 
(once to shadow memory and once to the 
screen). 

The second approach tries to alleviate 
these problems by saving only in off¬ 
screen buffers the covered portions. The 
graphics operators must be changed so a 
single operation will work partially on the 
screen and partially in an off-screen buf¬ 
fer. This clearly makes the graphics opera¬ 
tions more complex. There may be some 
operations provided by the hardware, 
such as filled polygons or circles, that can¬ 
not work separately on different parts of 
the picture. Saving the covered portions 
would be inappropriate in this case. Blit 
and Sapphire can use this approach since 
their graphics are limited mostly to raster- 
ops. 

The third approach calls for a general 
display list mechanism, such as that used 
on calligraphic (vector) screens, but this is 
inappropriate for a bitmap screen because 
saving a description of the picture may 
easily take more memory than the picture 
itself, especially for complex images. 
Refreshing from a display list also takes 
more time than refreshing from a stored 
picture, and it may be difficult to handle 
raster-selective erasures with display lists. 

The fourth approach calls for a mixed 
style such as a limited form of display list 
when appropriate. Because many windows 
contain only text, an obvious optimization 
is for those windows to save only the 
characters displayed in them rather than 
the bitmaps for the characters. This will 
typically save more than an order of 
magnitude of storage even on a one-bit- 
deep screen (nine by 13 characters take 117 
bits versus seven bits for the ASCII code). 
In systems where this has been imple¬ 
mented, however, such as the ICL PNX 
window manager, 4 many restrictions 
typically apply (for example, only one font 
per window, which must have a fixed 


width). Also, this might be of limited ap¬ 
plication since many text-only applica¬ 
tions, such as sophisticated text editors, 
use graphics as part of their user interfaces 
(such as MacWrite for the Macintosh). 10 

If an application handles window re¬ 
fresh, it must remember the contents of its 
window and regenerate the picture on de¬ 
mand. This is the approach in the Apple 
Macintosh 10 and IRIS Mex 6 window 
managers. Many programs, such as text 
and graphics editors, must save the con¬ 
tents of the window anyway, so it is easy 
for them to regenerate the screen picture 
when necessary. On the other hand, some 
applications may find it difficult to 
manage window refresh. The application 
program must be prepared to handle asyn¬ 
chronous refresh requests that may occur 
at any time, including while the program is 
modifying the picture. This may adversely 
affect the program’s structure and the ease 
of porting programs written for nonwin¬ 
dow systems. 

To provide maximum flexibility—and 
still conserve memory whenever possi¬ 
ble—Sapphire implements two methods, 
allowing the programmer the choice of 
automatic refresh by saving only covered 
portions off screen or of application- 
handled refresh. Providing application- 
handled refresh was partially based on the 
observation that although Blit uses the 
memory-saving techniques of the covered- 
portions approach, some of its pro¬ 
grams—such as the editor and debug¬ 
ger—use a different technique for covered 
subwindows to conserve memory. 

Providing automatic refresh lets normal 
windows be used as the temporary buffers 
often needed in interactive graphics (for 


example, to hold a series of pictures being 
transferred to the screen one by one for an 
animation). The program simply creates a 
window that has automatic refresh (so it 
has backup memory), positions the win¬ 
dow so it is entirely off screen, and then 
stores the picture in the window. Since the 
window is off screen, it will not be visible 
to users—but all the graphics operations 
will work normally, and the application 
can copy the contents of the window to the 
screen whenever desired. The window 
manager will also allocate and manage the 
temporary buffers automatically. 

Raster-op for covered 
windows 

Most computers provide little hardware 
support for the covered window para¬ 
digm. Therefore, to display only the por¬ 
tions of a window visible on the screen 
(and hide covered parts), window manag¬ 
ers implementing the covered window par¬ 
adigm in software must calculate which 
portions of windows are covered. This is 
especially true if the window manager 
allows graphics to appear in a window 
while the window is covered. (The Inter- 
lisp-D 11 and Smalltalk 8 window manag¬ 
ers only allow graphics to be output to un¬ 
covered windows. Interlisp-D automati¬ 
cally brings a window to the top before do¬ 
ing output graphics, which causes a great 
deal of flashing when multiple windows 
are being used. Most modern window 
managers support updates to any window 
at any time.) 

The window intersection information is 
usually precalculated and stored as a list of 


September 1986 


59 





















first line 


second line 

second line 


third line 

third line 

> 

penultimate line 

penultimate line 


last line 

last line 




Figure 3. When scrolling the left window up one line to get the configuration on the 
right, the first line must be moved first, overwriting the second line. If the third line is 
moved before the second, then the information in the second will be lost. 



Figure 4. Typical bitmap 
organization. The first pixel is 
in the upper left and there are k 
pixels across and n down. The 
dotted rectangle in the center 
is to be shifted either starting 
with pixel i or pixel /+ k+ 2. 
When moving the rectangle 
towards the upper left, for ex¬ 
ample, the pixel order will be 

/,/+1,f+2,/+*,/+#r+1, 

i+k+2. 
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Figure 5. (a) To move the rectangle in Figure 4 in any direction requires only two 
orders for the pixels, starting from the upper left pixel (ULP) or from the bottom 
right pixel (BRP). (b) Starting from the upper left pixel (i) is correct when shifting a 
rectangle to the upper right, while starting from the bottom right pixel (/+ k+ 2) 
would be incorrect since pixels /+ 1 and /+ 2 would be overwritten before they are 
moved. 


rectangles for each window, marked as 
visible (which means they appear on the 
screen) or covered (which means they are 
covered by other windows and not visible 
on the screen). Figure 2 shows the set of 
rectangles that would be generated for 
window W1 in Figure 1. 

When using window raster-op to trans¬ 
fer a picture to a new position that over¬ 
laps the old one, the order in which the bits 
are moved is important. It is important to 
note that the ordering problems discussed 
in this section are less relevant for window 
managers that use full window shadow bit¬ 
maps. For example, when scrolling up a 
window, the top must be moved before the 
bottom or else the bottom part will cover 
portions not yet transferred (see Figure 3). 
Window raster-ops of this form are used 
when scrolling text up or down in an editor 
or when panning a picture around in a 
graphics program. 

This problem is analogous to shifting 
the elements in a conventional array, 
where the shift must be done from the cor¬ 
rect end to avoid losing information. The 
hardware raster-op, like the conventional 
array shift, needs only two directions to 
work correctly: top to bottom and bottom 
to top (see Figure 4). When moving a rect¬ 
angle up or to the left, the hardware raster- 
op will first move the upper-leftmost bit, 
then the bit to its right, and so on as shown 
in Figure 5. When moving down or to the 
right, raster-op must start with the last bit. 

The covered-window raster-op applies 
the hardware raster-op to each rectangle 
(as in Figure 6) as a unit. It therefore must 
deal with the processing order of the rect¬ 
angles. In this case, four different orders 
are needed. 

Imagine a picture covering the three 
rectangles in Figure 6. When moving the 
picture to the upper right, the order for the 
rectangles must be B, C, A —or else some 
necessary portion will be overwritten. 
When going to the lower left, the order is 
A, C, B, which is the reverse of the order 
when going to the upper right. When go¬ 
ing to the upper left, however, the order is 
A, B, C—which does not have any natural 


Figure 6. (a) If the rectangles need to be moved to a 
new position overlapping the old position, the moving 
order is important, (b) The correct order for the eight 
directions. The orders for up, down, left, and right can 
be either of the orders on the neighboring diagonals. 
Rectangle B has no other rectangles in its upper right 
quadrant, so it can be moved to the upper right 
without interfering with other rectangles. 
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correspondence to the upper right/lower 
left order. The lower right order is the 
reverse of the upper left order: C, B, A. 
The order is always important, no matter 
whether the rectangles are stored in con¬ 
tiguous memory (all on the screen) or if 
they are each stored in separate buffers. 

The reason that two orders do not suf¬ 
fice for covered windows is that the ob¬ 
jects to be moved (rectangles in this case) 
are larger than the distance they can be 
moved, so the new positions partially 
overlap parts of the old positions. Simply 
making all the rectangles be squares of the 
same size would not solve the problem, as 
Figure 7 shows. 

In a more formal analysis, when going 
to the upper right, the rectangle whose up¬ 
per right quadrant does not overlap with 
any other rectangles must first be found 
(see Figure 6). This rectangle can be moved 
in any direction in the quadrant without 
affecting any other rectangles. Since there 
are a finite number of nonoverlapping 
rectangles, there will always be such a rect¬ 
angle. After this first rectangle is moved, it 
is eliminated from consideration and the 
next maximal rectangle is found. A similar 
operation is performed to move in the 
other four directions. 

Some window managers (such as Blit) 
sort the rectangles when the window 
raster-op is performed. To avoid this 
overhead, Sapphire uses a technique that 
generates the rectangles in the correct 
order. Because graphic operations are 
done much more frequently than recon¬ 
figuring the rectangles (which is done only 
when windows are created, deleted, or 
modified), it is more efficient to generate 
the rectangles in sorted order, as Sapphire 
does. 

The rectangles in Sapphire are stored in 
a quadruply linked list, one thread 
through the rectangles for each of the four 
orders. The window raster-op then follows 
the correct thread based on the direction 
of the window raster-op transfer. Each 
rectangle of the source is compared with 
each rectangle of the destination in the 
correct order, and any overlapping parts 
are transferred. It does not matter whether 
the source and destination windows are 
the same or different. Figure 8 gives an 
outline of the code for covered window 
raster-op. 

The window raster-op clearly takes 
0(n 2 ) time, where n is the number of rect¬ 
angles. The maximum number of rectan¬ 
gles in a window is a constant multiple of 
the number of windows, so n can be con¬ 
sidered to be the number of windows or 
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Figure 7. Even if all the rectangles are 
squares of the same size, four orders are 
needed if the new positions can overlap 
the old positions. 8 must be moved 
before A can move into the dotted posi¬ 
tion, and A must be moved before 8 can 
move there. 


Procedure WindowRasterOp(RasterFunction, SourceCoords, Destination- 
Coords) 

Calculate RasterOp direction from source and destination coordinates. 
FOR dr: = EACH destination rectangle is in order DO 
IF dr is not covered OR 

IF (dr is covered AND has backup memory) THEN 
dtmp: = Clip destination coords to dr 
IF anything left inside dtmp THEN 
FOR sr: =EACH source rectangle in order DO 
stmpl: = compute corresponding place in source for dtmp 
stmp2: = clip stmpl to bounds of sr 
IF anything is left inside stmp2 THEN 
IF sr is covered THEN {no picture in source for this area} 
save stmp2 on a list for update by the application 
ELSE 

do hardware RasterOp on stmp2 
get next source rectangle in the current order, 
get next destination rectangle in the current order. 

END Procedure WindowRasterOp 


Figure 8. Outline of the code for covered window raster-op in pseudo-Pascal. 



Figure 9. The dashed lines show the rectangles created for window IV when covered 
by windows W2, IV3, and W4. When transferring area A to area 8, there are 0(n 2 ) rect¬ 
angles to move, where n is the number of rectangles. Area C is covered by O(n) rect¬ 
angles, one for each window. 


the number of rectangles in any one 
window. 

The 0(n 2 ) complexity for window 
raster-op cannot be improved in the worst 
case, since the number of overlapping rec¬ 
tangles can be 0(n 2 ) because every rec¬ 
tangle in the source area may intersect with 
every rectangle in the destination area. 
This will happen, for example, when the 


source rectangles are all horizontal and the 
destination’s are all vertical, as shown by 
areas A and B in Figure 9. It is therefore 
not possible to write an algorithm that has 
less than quadratic complexity in the worst 
case. 

The general case can be made faster, 
however, by trying to limit the number of 
rectangles compared on average. For ex- 
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Figure 10. When window W1 is scrolled 
up, the picture appearing from behind 
window W2 needs to be displayed. If 
there is no backup memory for W1, the 
application must regenerate the picture 
for the dotted rectangle. 


ext. top 


ext. left 


window 


ext. right 


ext. bottom 


Figure 11. Special exterior rectangles 
surrounding a window. They extend to 
± oo (± max_integer). 


ample, the entire destination and source 
areas for the window raster-op can be 
compared to their respective rectangle lists 
to see which rectangles could be affected 
by the particular window raster-op (this is 
akin to the bounding box test often used to 
optimize other graphics operations). The 
comparison takes O(n) time and general¬ 
ly will probably save a lot of time, since 
many window raster-ops affect only one 
source and one destination rectangle. 

Many other optimizations are possible. 
For example, window raster-ops in un¬ 
covered windows (which have only one 
rectangle) can be performed directly with 
only a clip to the windows’ borders. 

The general hardware raster-op is often 
used to erase or invert a single rectangle. In 
this case, the source and destination rect¬ 
angles are identical. For example, a rect¬ 
angle can be set to white (0) by XORing it 
with itself. When the rectangles are the 
same, a much more efficient algorithm is 
used in Sapphire that goes through the list 
of rectangles only once and therefore has 
O(n) complexity. 


When performing a covered window 
raster-op, there are two cases where there 
may not be a picture available in the 
source. First, the source of the window 
raster-op might be a window that is 
covered and does not have backup mem¬ 
ory (and so uses application-handled 
refresh). An example of this is scrolling a 
text window where some text comes out 
from behind another window (see Figure 
10). The other case occurs when the 
specified source is outside a window. 
Some systems may flag this latter window 
raster-op as an error, but Sapphire allows 
it for consistency because the destination 
for graphics can extend outside the win¬ 
dow. Sapphire surrounds every window 
with four special rectangles (see Figure 11) 
for the exterior of the window that extends 
to ±oo (implemented as ± maxJnteger) 
away from the window. This makes it pos¬ 
sible to avoid a special case test and extra 
boundary clipping in the window raster- 
op code. 

Whenever parts of the source are not 
available, the rectangles in the destination 



Figure 12. The 17 two rectangles can interact. The numbers show the up left ordering, and the letters show the up right ordering. 
The down right ordering is the reverse of the up left, and the down left is the reverse of the up right. The solid rectangle is to be 
divided based on the dotted window. If the dotted window covers the solid one, the rectangle inside both the dotted and solid 
rectangles is covered. If the dotted window is the parent of the solid one, the area of the solid rectangle outside of the dotted area 
is covered. 
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for those parts are saved on a list and later 
passed to the appropriate application pro¬ 
gram for regeneration using an operating 
system exception mechanism. The appli¬ 
cation is told exactly what portions need to 
be regenerated so it does not waste time 
drawing intact parts (although it can if it 
wants to). 

Rectangle intersection 
algorithm 

The coordinate system for each window 
in Sapphire has 0,0 at the upper left cor¬ 
ner; x grows to the right and y grows 
down. The bounds of the window are 
therefore given by the lower right corner 
of the window and are inclusive. For 
graphics, however, coordinates can be 
used that are outside of the window 
(negative to the upper left or greater than 
the bounds for the lower right) and the 
picture is simply clipped to the inside of the 
window. 

Sapphire’s rectangle intersection algo¬ 
rithm is fairly simple. It is based on the 
straightforward enumeration of all the 
ways two rectangles can intersect. In each 
x and y direction, the rectangles can be 
covered in one of five ways. For x, they 
are left covered, middle covered, right 
covered, all covered, and not covered. The 
y values are similar. It turns out that if 
the rectangles do not intersect in either 
the x or the y direction, the rectangles do 
not overlap. There are thus 17 different 
possibilities (4x4+1). These are shown in 
Figure 12. 

The rectangles are optimized for max¬ 
imal horizontal extent. This direction was 
chosen to minimize the number of rectan¬ 
gles crossed in typical text operations 
(which are usually horizontal). The only 
difficulty in implementing the subdivision 
is to avoid fence-post errors. (Fence-post 
errors are ±1 errors. The name comes 
from the problem of determining how 
many posts are needed to fence a yard that 
is 10 feet long if one is placed every foot.) 
Each case splits the rectangle into one to 
five new rectangles, some covered and 
some visible. These rectangles are added to 
the four different rectangle lists in the cor¬ 
rect order. 

To demonstrate that this preserves the 
ordering, it must be proved that dividing 
one rectangle into a set of rectangles that 
replace the old rectangle in the list pre¬ 
serves the overall order. Imagine that rect¬ 
angle B in Figure 6 is to be divided. Since 
all the new rectangles will be entirely 


enclosed in the area of B, they all still must 
follow A and precede Cwhen going to the 
upper left. Therefore, if the new rectangles 
that replace B are in the correct order with 
respect to each other, they will be in the 
correct place with respect to A and C, and 
therefore with respect to the entire list. 


The procedure that implements the sub¬ 
dividing algorithm traverses each list from 
back to front and adds each new rectangle 
after the current rectangle, so newly added 
rectangles will not be investigated during 
the pass of the algorithm that creates 
them. Figure 13 gives an outline of the pro- 


Procedure WindowIntersect(W,RL, b: (wantOutside, wantlnside)) 

{intersect window W with the current rectangle list RL. b is wantOutside 
when W covers RL, b is wantlnside when W is parent of RL} 

{Rectangles in RL are screen coordinates} 

{RL is changed to have the new rectangle list} 

convert W’s coordinates to screen coordinates {so it can be compared to 
RL} 

FOR current: = EACH rectangle in RL starting with firstDownRight DO 
IF current is covered THEN { ignore since don’t need to subdivide 
covered rectangles} 

ELSE 

Calculate intersection between current and W in X and Y directions 
(as in Figure 12) 

IF either X OR Y not intersected THEN 
Change Current rectangle coveredness to be NOT wantOutside 
{doesn ‘t intersect} 

ELSE 

CASE x interaction OF 
xleftCov: CASE y interaction OF 

ytopCov: {first create rectangles and add to the upLeft, 
downRight lists} 

t2 : = AddUpLeft(current, 2a, b = wantlnside) 

{t2 becomes upLeft of current. Last argument to 
AddUpLeft is coveredness of the new rectangle} 
t3 : = AddUpLeft(t2, 3c, b = wantlnside) 

{next, change size and position of tl to be lb; last 
arg is coveredness} 

tl := Change(current, lb, b = wantOutside) 

{now add new rectangles to the upRight, 
downLeft lists} 

AddDownLeft(tl, t2) {t2 becomes downLeft of tl} 
AddUpRight(tl, t3) {t3 becomes upRight of tl} 
ymiddleCov: 

t2 : = AddUpLeft(current, 2c, b = wantOutside) 
t3 : = AddUpLeft(t2, 3b, b = wantlnside) 
t4 = AddUpLeft(t3, 4d, b = wantlnside) 
tl := Change(current, la, b = wantlnside) 
AddDownLeft(tl, t3) {t3 becomes downLeft of tl} 
AddDownLeft(t3, t2) 

AddDownLeft(t2,t4) 

ybottomCov:... 

yallCov:... 

END CASE on y 

xrightCov: CASE y interaction OF 
END CASE on x 

current: = next downRight from current 
END Procedure Windowlntersect 


Figure 13. Outline of the code to do rectangle subdivision. There are four cases for x 
in the outer case statement. Each branch of the case has four cases for y, making 16 
cases. The 17th case is the special test for not intersecting performed before the 
cases. In each branch, the numbers (like 2a, 3c) correspond to the rectangle label in 
Figure 11. All 16 case branches are similar to the ones shown. 
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Figure 14. W2 is a subwindow of W1, so 
it is clipped to the boundary of W1. The 
part of W2that is outside of Wf is marked 
covered (and are not visible). The part of 
W1 that is underneath W2 is covered. 



Procedure OuterLoopIntersectWindows(W) 

[Calculates the rectangle list for window W. 

The list is stored in the local variable RL. J 
RL : = rectangle for W converted to screen coordinates [start rectangle list 
with one rectangle for the entire inside of W\ 

IF W is offscreen THEN 

Set RL to be covered [ optimization } 

ELSE 

[* first, clip to the inside of parent and its parent, etc. *) 
t: = W’s parent window 
WHILE t < > NIL DO 

Call WindowIntersect(t, RL, wantlnside) [get the inside oft ) 
t: = t’s parent window [go up the window hierarchy ] 

[* next, remove areas covered by my immediate children *] 

FOR t: = EACH immediate child window of W DO 
Call WindowIntersect(t, RL, wantOutside) [get the outside of t] 
t: = next child of W 

(* finally, check all other windows that might cover W *) 
t := W 

WHILE t’s parent < > NIL DO 

FOR t2 : = EACH sibling window of t that is higher priority (more 
towards the top) than t DO 
Call WindowIntersect(t2, RL, wantOutside) [outside ) 
t2 : = next sibling 

t: = t’s parent window [go up the window hierarchy] 

[clean up] 

convert RL to be in W’s coordinate system 
add the exterior rectangles 
set W’s rectangle list to be RL 
END Procedure Outer LoopIntersectWindows 


Figure 15. Outline of the code for the main loop for calculating window’s covered¬ 
ness. The procedure Windowlntersect is outlined in Figure 13. 


Figure 16. Bringing window W more for¬ 
ward (towards the top) can only affect 
certain windows. 


cedure. The algorithm has quadratic com¬ 
plexity, but this is inherent in the problem 
since, in the worst case, the number of 
rectangles that can be created in one win¬ 



dow intersecting with n other windows is 
n 2 , as shown in Figure 9. Since this 
algorithm will be run on all n windows, the 
total complexity is 0(n 3 ). 


This is also inherent in the problem. 
Since each covered portion of the screen 
will be represented by a rectangle for each 
window on it (the area marked C in Figure 
8 is represented by n rectangles, one for 
each window covering that area), the total 
number of rectangles for all windows is 
0(n 3 ). There are some heuristics avail¬ 
able, however, to improve the general 
case. These include trying to limit the 
number of windows processed (for exam¬ 
ple, by ignoring windows that are totally 
off screen) and trying to run the algorithm 
as few times as possible. 

Sapphire implements subwindows. Sub¬ 
windows can overlap within their parent 
and may extend outside the parent win¬ 
dow, but any parts outside are clipped and 
not visible, as Figure 14 shows. Because 
the screen is represented as the parent of all 
other windows, it is trivial to let windows 
extend partially or totally off screen. This 
also makes it easy to change the screen size 
(the PERQ can be configured with various 
screen sizes), and some of the memory 
normally used for the screen can be 
allocated to other applications by reducing 
the screen window size. The extension to 
the subdivision algorithm to handle sub¬ 
windows is very simple (see Figure 13). 
When clipping a subwindow to its parent, 
the identical algorithm is used—except 
areas inside the parent are visible and areas 
outside are covered, which is the reverse of 
the case for overlapping windows pre¬ 
sented above. Subwindows can recursively 
contain their own subwindows to an ar¬ 
bitrary depth. 

Because subwindows cover the parent 
window, the immediate subwindows of a 
window affect that window’s rectangles 
(see Figure 14). Subwindows of sibling 
windows do not have to be investigated, 
however, because they are entirely en¬ 
closed within the sibling window. An out¬ 
line for the outer loop for window sub¬ 
division is shown in Figure 15. All the 
calculations are done in screen coordinates 
to make it easier to compare different 
windows. 

As the final step of the algorithm, the 
rectangles are converted into the window’s 
coordinate system. As part of this step, the 
rectangles are associated with the memory 
that will hold their picture: some rect¬ 
angles correspond to windows on the 
screen and others correspond to off-screen 
memory holding covered portions of the 
picture. If the window does not have off¬ 
screen memory (so the application must 
handle refresh), the rectangles for covered 
parts are marked as having no memory to 
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hold the associated picture. Output to 
these portions will simply disappear (as 
shown in Figure 8). Also in this step, the 
four special rectangles for the exterior of 
the window (Figure 11) are added to the 
four rectangle lists in the correct order. 

Manipulation 

operations 

Top, bottom, create, and delete. Mak¬ 
ing a window less covered (towards the 
top) requires two steps. First, any portions 
of the other windows that become covered 
must be stored in their backup memory. 
Then portions of the window brought for¬ 
ward that become uncovered must be 
regenerated. Most systems only allow win¬ 
dows to be brought to the top (so they are 
not covered by any windows) or sent to the 
bottom. With window raster-op, Sapphire 
lets windows be moved to any position in 
the covering order. In the following 
description, the window being changed is 
called W. 

First, Sapphire checks those windows 
closer to the front (less covered) than IF’s 
old place and less covered than W s new 
place (see Figure 16). Only these windows 
can be affected by the change. For each of 
these windows. Sapphire checks to see if 
its entire area intersects with the entire 
area for W. If so, all its subwindows are 
checked, since some may also be affected. 
For each affected window, the old rectan¬ 
gle list is saved and the new list is generated 
for the window with the new covering. 

To do the actual update, Sapphire sim¬ 
ply calls window raster-op to transfer from 
the old rectangle list to the new one. The 
standard window raster-op call (which 
takes two windows as parameters) is used 
by having a dummy window to which the 
old rectangle list is assigned. If the affected 
window had backup memory, the window 
raster-op will automatically move any 
newly covered portions to the backup 
memory. 

After each affected window is updated, 
a similar operation is performed for W 
itself. Here, however, the window raster- 
op will copy from backup memory any 
portions of W that become uncovered. If 
W did not have backup memory, the win¬ 
dow raster-op will inform the appropriate 
application program to regenerate the cor¬ 
rect portions of W. Creating a new win¬ 
dow is similar to moving it from the bot¬ 
tom (the old rectangle list is empty). 

Making a window more covered uses 
the same technique—but in reverse. In this 


case, the windows more covered than W's 
old position and less covered than U^s new 
position are checked to see if any portions 
must be regenerated. The actual regenera¬ 
tion is done in the same manner as for top, 
except that W itself is handled before the 
other affected windows, since any por¬ 
tions that become covered in W must be 
saved to backup memory before the screen 
is overwritten by the newly uncovered 
windows. 

Deleting a window works the same as 
sending it to the bottom. 

Move and grow. Move and grow are 
much more complicated than top and bot¬ 
tom since as much of the original picture 
as possible should be retained without 
using extra temporary buffers, and sub¬ 
windows should move with the parent 
window (so the subwindows remain in the 
same relative places within the parent win¬ 
dow). Another requirement is that win¬ 
dows be movable even while being covered 
by other windows in the source or destina¬ 
tion. Sapphire therefore transfers as much 
of the old picture as possible to the new 
location and only requires the application 
to refresh what is absolutely necessary. 
Because the screen contains the only copy 
of the picture for the visible parts of the 
window, no screen picture should be 
destroyed before it is moved. 

Having subwindows also complicates 
the modify operation. Clearly, if the win¬ 
dow is made bigger, the application will 
need to adjust the picture (and possibly the 
subwindows) to fill in the new areas, so it 
must notified. In other cases, however, the 
application can remain uninvolved. Move 
and grow are implemented by one pro¬ 
cedure, called modify. 

Again we call the window being 
modified “ W. ” The modify procedure is a 
three-step process (see Figure 17). First, all 
areas covered by IPs new position must be 
copied into their backup memory (if any). 
The algorithm for implementing this is 
similar to that used when W is brought to 
the top. Second, the picture for W must be 
moved to its new position. Third, any win¬ 
dows that become exposed must be regen¬ 
erated. The algorithm for the last step is 
similar to that used to send W to the bot¬ 
tom. The calculations for the first step 
must take into account IT’s old position as 
well as its new position, so portions of IP’s 
screen picture are not overwritten. There¬ 
fore, some windows may be updated twice 
if they are affected by both W^s new and 
old positions. 

Step 2, where W itself is modified, turns 



Figure 17. Modifying a window is a three 
step process. First, windows affected by 
M/’s new place (W1, M/3, and W4) have 
their newly covered portions stored to 
backup memory. Second, M/’s picture is 
moved to the new place. Third, windows 
that need to be refreshed because por¬ 
tions are no longer covered by M/ (M/7, 

W2, and W3) are regenerated. Note that 
M/7 and W3are affected twice. 

out to be surprisingly difficult. W may be 
covered in different ways at its source and 
destination, and its new position may 
overlap its own old position (see Figure 
17). A further problem is that the screen 
picture for the entire window must be 
moved as a unit—including the pictures in 
any subwindows. Neither the window nor 
its subwindows can be moved indepen¬ 
dently since they may overlap at the source 
and destination (see Figure 18). Therefore, 
to move the window itself, the following 
three steps are performed: 

First, any portions of the window and 
all of its subwindows that will be covered 
in the destination position are saved into 
backup memory with a special version of 
the covered window raster-op that only 
transfers the covered parts of the destina¬ 
tion and ignores the uncovered parts. 

Second, the screen picture from the old 
location is transferred to the new location. 
To do this, Sapphire must calculate the 
covered rectangle sets for the old and new 
locations, ignoring all of IF’s subwin¬ 
dows. The new rectangle lists are needed 
because W may be covered by other win¬ 
dows (not subwindows of W) at both the 
source and destination, as shown in Figure 
18. Any backup memory that W might 
have is ignored here. 

Third, any parts of the picture for IVor 
its subwindows that become exposed are 
transferred to the screen from backup 
memory or redrawn by the application 
program (if there is no backup memory). 

When changing a window’s size, it is 
often inappropriate merely to adjust the 
subwindows’ size proportionally to the 
parent’s, since some subwindows may 
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Figure 18. When Wl is moved, its subwindow W2 moves with it so that it remains in 
the same relative place inside Wl. The screen picture for Wl and W2 cannot be moved 
separately to the new position. Imagine that Wl is to be moved slightly to the right. If 
the subwindow is moved first inside Wl, the part of Wl marked a will be erased. If the 
uncovered part of Wl (gray area) is moved first, the portion of W2 marked b will be 
erased. Therefore, the entire picture (Wl including W2) must be moved as a unit, but 
window W3 must still not be affected. 


have special size constraints. For example, 
a header subwindow may be exactly one 
text line high, irrespective of the window 
size. Therefore, Sapphire leaves all sub¬ 
windows the same size and in the same 
relative position with respect to the origin 
of the parent window, and notifies the ap¬ 
propriate application program of the win¬ 
dow’s size change so it can reconfigure the 
subwindows (if necessary). 

Although window modification is fairly 
complex, it does maintain the most infor¬ 
mation possible and provides a great deal 
of flexibility. When a window has no sub¬ 
windows, many of the above steps are 
omitted. Because windows are moved 
rarely and only at a user’s command, the 
modify procedure has proved acceptable. 

Efficiency comparison 

The covered window paradigm has been 
around for a fairly long time. It was 
developed at the Xerox Palo Alto (Calif.) 
Research Center in the Smalltalk 8 and In¬ 
terlisp 11 environments. These and other 
early implementations of covered win¬ 
dows typically only allowed applications 
to update a window if it was not covered. 
The Blit window manager, 5 which does 
provide output to covered windows, was 
probably the first covered window system 
to have its implementation openly pub¬ 
lished. Sapphire implements a superset of 
Blit’s features. 

For example, the Blit implementation 
only provides automatic refresh with 
saved bitmaps, while Sapphire allows 
application-handled or automatic refresh. 
Also, Blit does not support subwindows or 
changing a window’s size. (The change- 
size operation on Blit is implemented by 
deleting the window and recreating it, and 
therefore losing the contents of the win¬ 
dow.) There are many other window manag¬ 
ers supporting covered windows today, 1,3 ‘ 11 


but their algorithms are usually pro¬ 
prietary, so efficiency comparisons are 
difficult. 

Sapphire was influenced by many of these 
systems; but the algorithms described here 
are original. 

For most operations, Sapphire and Blit 
have the same complexity. For example, 
window raster-op in both is 0(n 2 ) (where 
n is the number of windows). In the rec¬ 
tangle intersection algorithm, Sapphire’s 
complexity is the same as for Blit (0(« 3 ) 
for all rectangles for all windows). Sap¬ 
phire may create fewer rectangles because 
covered rectangles are not subdivided as 
they are in Blit, but this saving may be 
overridden in practice by the four exterior 
rectangles. The WHIM window manager 3 
essentially uses the Blit algorithm, but 
does not subdivide covered rectangles, so 
it will have fewer rectangles. 

When doing a window raster-op. Blit 
must sort the rectangles. In Sapphire, the 
rectangles are already sorted. The disad¬ 
vantage of Sapphire’s technique, however, 
is that the full intersection algorithm must 
be run whenever windows are manipu¬ 
lated, while Blit must only transfer some 
rectangles from one window to another. 
(Of course, this is done only when win¬ 
dows are moved, created, deleted, grown, 
or reduced.) Sapphire has been optimized, 
however, for the case where a window 
simply becomes more covered (sent to the 
bottom). Here, the existing rectangle set is 
simply intersected with the new window. 
This is much faster than recreating the 
rectangle list from scratch and is about as 
efficient as the Blit technique, while 
preserving the rectangle order. 

The major time-critical part of Sapphire 
is the window raster-op itself. Some mea¬ 
surements show that, in many operations, 
the covered window raster-op overhead 
over the hardware raster-op is quite 


substantial. This is partially due to the 
large number of rectangles for typical win¬ 
dows. The average number of rectangles 
for covered windows has been measured as 
eight (which includes the four exterior 
rectangles) while some windows, such as 
the full-screen window, often have more 
than 60 rectangles. 

The Sapphire optimizations have in¬ 
creased the window raster-op efficiency by 
a factor of two on average and a factor of 
10 in certain special cases. Window raster- 
ops in uncovered windows bypass the ex¬ 
pensive algorithm altogether and there¬ 
fore perform almost at the hardware 
raster-op’s speed. Of course, the window 
raster-op overhead could be vastly re¬ 
duced by coding it in microcode. If the 
covered window raster-op is made faster, 
it will not only help applications but also 
Sapphire itself, since window raster-op 
performs all window manipulations. 

Another area of efficiency is memory 
usage. In the Accent operating system sup¬ 
porting Sapphire, it is very expensive to 
allocate memory for pictures. Therefore, 
whenever a window is created with backup 
memory, enough memory is allocated for 
the entire window, even though only parts 
of the window may be covered. This will 
clearly waste a lot of memory. During up¬ 
dates, the appropriate parts of the mem¬ 
ory buffer are addressed for the covered 
portions of the window. (The rest of the 
buffer is left unused.) 

The window intersection algorithm 
allows memory allocation and dealloca¬ 
tion that can be added easily if the 
operating system makes this feasible. 
When a window’s covering changes, how¬ 
ever, two pieces of memory would be al¬ 
located during the update (as in WHIM 3 ). 
The old memory would be released after 
the update was completed. On Blit, only as 
much memory as needed is allocated, and 
an XOR swap transfers pictures from one 
buffer to another. Sapphire could use this 
technique if the temporary extra memory 
usage was a problem, but this takes three 
hardware raster-ops instead of the two 
now used. 

The theoretical efficiency of a window 
manager is not nearly as interesting as the 
measured performance of actual proce¬ 
dures. Unfortunately, many of the optimi¬ 
zations applied to Sapphire have proved 
ineffective because a much larger propor¬ 
tion of the time is actually spent in 
operating system interprocess communi¬ 
cation. The Accent 2 operating system uses 
message passing with separate address 
spaces for separate processes, and Sap- 
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phire is implemented as a separate process 
from all applications for protection and 
structured design. 

Unfortunately, the time to send a mes¬ 
sage to Sapphire, along with the required 
process swapping, swamps the time to per¬ 
form the actual graphics. Therefore, the 
most worthwhile optimization is allowing 
applications to do graphics directly to un¬ 
covered windows and thereby eliminate 
the message to Sapphire. To provide the 
necessary protection and synchronization, 
however, this optimization has required 
that more of the window manager be im¬ 
plemented in the operating system kernel. 
Unfortunately, the current design does not 
allow applications to do raster-ops to 
covered windows without a message to 
Sapphire, since Sapphire stores the rect¬ 
angle lists in its private address space. 


T he algorithms performing covered 
window operations in Sapphire have 
many advantages over other algo¬ 
rithms. These include application-handled 
or automatic refresh, moves, and size 
changes of windows, support for subwin¬ 
dows, and generally more efficient win¬ 
dow raster-ops because the rectangle lists 
are always kept sorted. Some of this flex¬ 
ibility does not appear to be required in 
practice. For example, windows virtually 
never change coveredness except to the top 
or bottom, and it is rare to change a win¬ 
dow’s size or position while it is covered by 
other windows. Also, applications rarely 
create sub windows that overlap. 

More investigation needs to be done on 
what techniques and facilities are impor¬ 
tant in practice and on efficient ways of 
implementing them. Also, as graphics 
hardware supports more sophisticated 
operations, such as color and 3D transfor¬ 
mations, as in the IRIS, 6 methods for win¬ 
dowing these must be investigated. It will 
also be useful to gather statistics on typical 
window manager use and efficiencies to 
evaluate the trade-offs between simple 
shadow bitmaps, complex clipping algo¬ 
rithms as described here, and application- 
handled refresh. 

The Sapphire implementation demon¬ 
strates that full-functionality covered win¬ 
dows can be provided while saving only 
the covered portions off screen. Whether 
these algorithms will be appropriate de¬ 
pends on the particular circumstances, but 
the general principles and complexity 
results will continue to be important. □ 
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THE CONFERENCE 


The 1986 IEEE INTERNATIONAL CONFERENCE ON COMPUTER-AIDED DESIGN will 
beheld November 10-13, 1986, in Santa Clara, CA. The conference concentrates on CAD 
for electronic circuit design, and features 1 day of tutorials and workshops, and 3 days of 
technical papers from an internationally recognized group of CAD experts. 

-TECHNICAL SESSIONS - 

The thirty-six technical sessions at ICCAD-86 fall into four general categories: systems, simulation, 
test, and layout. A partial list of topics is shown below. 


• Gate Matrix Layout 

• Global and Detailed Routing 

• CAD Tool Integration 

• Simulation on Multiprocessors 

• Hardware Accelerators 

• Module Generation 

• Layout and Behavioral Synthesis 


• Design for Testability 

• CAD for Process Design 

• Circuit Simulation 

• Fault Simulation 

• Global and Detailed Routing 

• Timing Analysis 

• Interconnection Modelling 


The evening of Tuesday, Nov. 11, 1986, will feature 2 outstanding panel sessions. 

• Is There a Future in Parallel Processing for • which Operating System Will Win for CAD? 

CAD Applications? 

-WORKSHOPS AND TUTORIALS- 


On Monday, Nov. 10, 1986, ICCAD-86 will sponsor five all-day workshops and tutorials: 


• Silicon Compilation • Design-for-Testability 

• VLSI Layout • Information Management for Engineering 

• EDIF Workshop Design 

-NOTE TO CAD/CAE VENDORS- 

Although there are no exhibits at ICCAD-86, a limited number of suites will be available at the conference hotel for vendors to 
hold in-depth technical discussions of their products. Contact M.P. Associates for details. 

-FOR FURTHER INFORMATION- 


Contact M.P. Associates, 7366 Old Mill Trail, Suite 101, Boulder, CO 80301 Telephone: (303) 530-4562 
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ADVANCE CONFERENCE REGISTRATION FORM 

4TH INTERNATIONAL CONFERENCE ON COMPUTER AIDED DESIGN 

November 10 - November 13,1986 


REGISTRATION DESK 

Advance registrants may pick up the conference materials and others may 
register during the conference at the registration desk located in the 
Ballroom Area. 

The registration desk will be open: 

Sunday, November 9.6:00 p.m.-9:00 p.m. 

Monday, November 10*.7:30 a.m.-9:00 a.m. 

Monday, November 10.9:00 a.m.-9:00 p.m. 

Tuesday, November 11.8:00 a.m.-4:00 p.m. 

Wednesday, November 12.8:00 a.m.-4:00 p.m. 

Thursday, November 13.8:00 a.m.-2:00 p.m. 

*Tutorial check-in begins at 7:30 a.m. on Monday, 11/10. 


All advance registration must be received before October 10, 1986. At-site 
conference payments can be made by check or cash - no credit cards will be 
accepted. No refunds unless cancellation is received before November 4, 
1986. 


Address _ 

City - State_ Zip 


REGISTRATION FEES [Includes] 

Cocktail party on Monday and Tuesday evenings, banquet dinner 
Wednesday evening and conference Digest of Technical Papers. 


Country - IEEE/ACM Membership No. 

_ Speaker _ Session Chairman 


IEEE/ACM Members 

Non-Members 

Students 


Before 10/10/86 
$150 
195 
75 


After 10/10/86 
$195 
250 
100 


Tutorials and Workshop Fees (conference registration also required) 
IEEE/ACM Members $120 150 

Non-Members 150 190 

EDIF 60 

(Please indicate first and second choices) 

_ ** Silicon Compilation 

_ ** Information Management for Engineering Design 

_ ** VLSI Layout - A Practitioner’s Overview 

_ ** Design for Testability 

_ ** EDIF Workshop 

_ Extra Digests ($30.00 each) 


Conference Fees enclosed: 

$_ IEEE/ACM Member $_ Non-member $_ Student 

Tutorial and Workshop Fees enclosed: 

$_ IEEE/ACM Member $_ Non-Member $_ EDIF 

$_ Extra Digests $_ Guest Registration 

Total Fees: $_ 

**Advance Registration for tutorials and workshops is advised since atten¬ 
dance is limited. 

Tutorial & Workshop registrants must also register for full conference. 
Please mail registration form and checks made payable to: 

ICCAD-86 

7366 Old Mill Trail, Suite 101 Boulder CO 80301 (303) 530-4562 

For travel arrangements and assistance, call Mission Park Travel at (408) 
980-1000. 


HOTEL REGISTRATION FORM 

4TH INTERNATIONAL CONFERENCE ON COMPUTER AIDED DESIGN 

November 10 - November 13, 1986 


Room reservations must be made directly with the hotel of your choice. A 
block of rooms has been reserved at the Doubletree and at the Santa Clara 
Marriott. The Doubletree is located beside and attached to the Santa Clara 
Convention Center and the Marriott is about four blocks away. 

ROOM RATES: 

Doubletree $84.00 single $94.00 double 

Marriott 84.00 single 94.00 double 

Reservations received after October 26, 1986 will be subject to availability. 
Be sure to specify that you are attending ICCAD when calling the hotel for 
reservations to be assured that you receive the conference rate, or complete 
the form below and send to: 

Doubletree Hotel Santa Clara Marriott 

5101 Great America Parkway 2700 Mission College Blvd. 

Santa Clara, CA 95054 Santa Clara, CA 95054 

(800) 528-0444 (408) 988-1500 


Company _ Mail Stop 

Street Address - 


City _ State _ Zip- 

Date _ Time _ PM 

Departure AM 

Date _ Time - PM 

Your reservation will be confirmed by the hotel. A first night’s deposit is 
required to confirm your reservation for arrival after 6:00 p.m. 

□ Visa □ American Express □ Mastercard 


NOTE: Hotel reservation forms sent to conference registration will be 
discarded. 


Date 




































Imbalance Between Growth and Funding in Academic Computer Science: 

Two Trends Colliding 

A Report Endorsed by the Computer Science Board 
and Prepared by the Computer Science Board's 
Committee on Research Funding in Computer Science 
David Gries, Cornell University 
Raymond Miller, Georgia Institute of Technology 
Robert Ritchie, Xerox PARC 

Paul Young (Committee Chair), University of Washington 


A cademic CS departments have experienced large in¬ 
creases in undergraduate and graduate enrollments dur¬ 
ing the first half of the 1980s. In order to handle the in¬ 
creases, universities have allocated significant new funds to CS, 
and this in turn has caused significant growth in the number of 
departments and their sizes. After almost 10 years in the 1970s 
and early 1980s of relatively constant PhD production, depart¬ 
ments are now increasing PhD productivity. 

This growth is seriously threatened by current and projected 
federal funding patterns and by possible loss of industrial support 
caused by impending and proposed changes in tax laws. The 
situation will only get worse if universities continue to expand 
departments and enrollments without increased funding for basic 
research. 


This abridged version of the original report is being copublished by ACM and the 
IEEE Computer Society. It leaves out many facts, tables, arguments, and references 
contained in the original 31- page document. Copies of the original report can be ob¬ 
tained from the authors. 


And yet, expansion in CS is needed both to meet national de¬ 
mand for research computer scientists and to allow for the 
nation’s expected future growth in the area. 

This report documents growth in CS, analyzes prospects for its 
continuation, and discusses the relationship between growth in 
personnel and funding. It concludes that from 1977 to 1985 fund¬ 
ing did not keep pace with growth in the field, that the problem 
has gotten worse rather than better in the past few years, that cur¬ 
rent policies preclude growth in funding for basic research, and 
that immediate policy changes are necessary to achieve needed 
growth. 

This report does not highlight past achievements, describe ex¬ 
pected successes in the future, or analyze the importance of the 
field to the nation’s well-being. Some of these issues have been 
considered in the Feldman Report 1 and Snowbird Report. 2 * 
There have been discussions since then—for example, references 


•Snowbird is the biennial meeting of chairpeople of PhD-granting CS depart- 


Executive summary 

Imbalances 

Research in computer science, or CS, plays an 
increasingly vital role in our nation’s efforts to maintain 
technological leadership in today’s information society. 
Interest in the field and demand for its personnel have 
caused steady growth in academic CS, but federal funding 
for CS basic research, the lifeblood of departments, has 
signally failed to keep pace with growth. In fact, successful 
stimulation of experimental work has been at the direct 
expense of the basic support needed to sustain it at 
required levels. Failure to change funding policies will have 
serious consequences for research and education. The 
situation has been worsening for several years and can no 
longer be ignored. 

Because data for computer engineering are often reported 
under electrical engineering, or EE, it is often impossible to 
obtain. However, we believe that CS and computer educa¬ 
tion, or CE, have similar funding and growth patterns and 
similar problems. 

There has been absolute growth in CS funding over the 
past 15 years, but this growth should not blind us to several 
facts: 

• The annual estimated demand for PhD’s in CS (over 
1000) far outstrips the supply (325) and is expected to do so 
for some time. 

• Most fields are growing slowly, if at all; CS is growing 
rapidly. The number of awarded bachelor's degrees doubled 


in a recent four-year period. PhD production is increasing 
8-10 percent per year. The increase in faculty in existing 
PhD-granting departments of 8 percent per year in the past 
five years is expected to continue through 1990. From 1978 
to 1984, 60 graduate programs were created. There is a large 
unfilled demand for CS faculty in non-PhD-granting 
departments. 

• From 1978 to 1985, both total-federal and NSF-specific 
constant-dollar funding for basic research in CS failed to 
grow as rapidly as the number of academic personnel. In all 
other related major fields, they grew more rapidly. For 
example, growths of NSF constant-dollar obligations and 
graduate enrollments in PhD-granting institutions were: 56 
percent and 109 percent for CS; 61 and 45 for engineering; 
and 54 and 11 for mathematics. 

• In the period from 1982 to 1985, CS percentage 
increases in total-federal and in NSF constant-dollar funding 
for basic research were smaller than in all other major 
scientific disciplines—even ignoring growth in personnel. 

• The shift from theoretical to experimental research has 
caused a shift of funding in NSF from individual grants to 
equipment grants and the Coordinated Experimental 
Research, or CER, program. Consequently, from 1979 to 
1985, NSF constant-dollar funds for individual grants 
declined from $24.4 to $22.4 million in 1985 dollars, even 
though the field grew substantially. 

• Failure to distinguish between computer usage and 
computer science has contributed to overestimations of CS 
funding. For example, new initiatives for scientific comput¬ 
ing and supercomputers are often viewed as helping CS, but 
are mostly benefiting scientists in other disciplines. 
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3,4, and 5—but fresh discussions would be worthwhile, perhaps 
under the auspices of the National Research Council, similar to 
the study of mathematics that resulted in the David Report. 6 ** 

Before beginning a detailed analysis, several points can be ad¬ 
dressed briefly here. First, our mention of the need for increased 
PhD production will raise the question of future oversupply. In 
CS, the 1985 PhD production was 325, but estimates of need con¬ 
sistently range well over 1000. At an annual increase of 10 per¬ 
cent, it would take six years to reach 600 PhD’s per year and 12 to 
reach 1000. This slow, controlled growth of 10-12 percent per year 
requires commensurate growth in funding. 

A second point concerns the nature of CS research and its cost. 
CS has increasingly become a laboratory discipline, with more 
and more researchers working on group projects and requiring 
equipment. For the late 1970s, Feldman' estimated capitalization 
in leading industrial labs at $40,000 to $60,000 per researcher. For 
the early 1980s, the Snowbird Report 2 estimated the cost of well- 
equipped academic labs at $55,000 to $75,000. Now, several 
departments that in the 1970s were 80 percent paper-and-pencil 
operations have research computing facilities valued at over $3 
million—$100,000 or more per faculty researcher (not including 
graduate students). Departments lacking adequate capitalization 
find it increasingly difficult to establish and maintain strong 
research and graduate programs. 3 

Other scientific Fields have had equipment and infrastructure 
for research and instruction for a long time; CS has only recently 
begun the struggle to obtain them. At a time when basic research 
support is not growing but departments are, the struggle is even 
harder. The problem is compounded by high maintenance rates 
and rapidly obsolescent equipment. A third point is the need for 
basic research in CS in academia. CS education is still in a state of 
transition. In departments that are abreast of current results, 


"The David Report suggests 800 new PhD’s per year in math as a reasonable 
steady-state target, an increase of 100, and requests an increase of 18 percent growth 
per year for each of the next five years. It recommends, each year, 1000 one-year 
graduate fellowships, 200 two-year postdocs, 400 special research grants for young 
PhD investigators, and research support for 2600 established mathematicians. CS, 
which looks forward to raising its PhD production from 300 to 1000, welcomes these 
guidelines in establishing guidelines for its own support levels. 


research ideas find their way into the curricula, even at the 
undergraduate level, perhaps more quickly than in other fields. A 
program that does not keep up with current research quickly 
becomes obsolete, and undergraduate programs in departments 
in which faculty are primarily from other disciplines are often at a 
disadvantage. More so than in most areas, maintaining up-to- 
date degree programs requires keeping abreast of current 
research, and the one effective way to do this well in a fast-moving 
field is by direct involvement in basic research. 

Also, industry is often more interested in the development of 
relatively short-range technology than in the production of new 
ideas and concepts. Thus, as shown in the Feldman Report, 
long-range basic research conducted in CS departments is often 
the origin of ideas and prototypes that later find important com¬ 
mercial, scientific, and military applications. 

A final point is that the data published for CS and CE are inac¬ 
curate and must be analyzed with care. The reasons for the inac¬ 
curacies are the rapid emergence and growth of the field, causing 
periodic changes in methods of reporting data, and the confusion 
between computer science and computing (as practiced by scien¬ 
tists in other fields). Appendix A discusses these problems. 

Background 

In the late 1970s, the CS community was seriously concerned 
about the health of academic CS. Salaries were not competitive 
with industrial salaries, computing equipment was sadly lacking, 
enrollments were rising rapidly, and too many noncomputer 
scientists tended to view the field simply as programming. The up¬ 
shot was the desertion of academia by faculty and PhD-quality 
students for industrial careers. The problems were discussed at 
length in reference 4 and were a major concern of department 
chairpeople. 2 

Since the 1970s, there have been substantial changes. The core 
curriculum has been moving from a sequence of programming 
courses to a set of core courses dealing extensively with fun¬ 
damental concepts. Experimental, “hands-on” aspects have 
been increasingly introduced into new instructional labs. 3 ’ 5 New 
departments have been formed, existing facilities have been 
enlarged, and faculties in PhD-granting departments have been 


The trends show that, at least implicitly, national funding 
policies now favor growth of basic research in CS at a 
smaller rate than in other scientific and engineering 
disciplines. Unless these policies are changed, an inade¬ 
quate research environment may once again force the 
departure of our best faculty and students to industry. 
Academic CS and CE are too vital to our nation’s intellec¬ 
tual, economic, and security needs to allow such decay. 

Recommendations 

Federal agencies, universities, and industry together 
should develop a long-range plan to support an increase in 
PhD production at an annual rate of 10-12 percent. NSF, the 
prime source of funding for peer-reviewed research, should 
lead the way by immediately reversing the current trend in 
its CS funding. Growth in funding of perhaps 15 percent per 
year is needed until PhD production balances demand. The 
following are recommendations for achieving such a goal: 

• Immediately raise NSF funds for individual grants in CS 
so that funds per submitted proposal (in constant dollars) 
are at least at their 1979 level. Thereafter, increase funds to 
allow for growth, for the increasingly experimental nature of 
the discipline, and for the need for infrastructure. 

• Support every PhD student through a fellowship, 
research assistantship, or teaching assistantship. Offer 300 
new four-year fellowships from industry, university, and 
federal funds each year. 

• Establish postdoctorals to help new PhD’s begin more 


productive research careers. These should be two-year posi¬ 
tions at the leading research centers, with salaries to attract 
the best people. Beginning with an additional 50 positions, 
the program should grow to 250 supported postdocs per 
year within five years. 

• Provide special three-year research grants for new facul¬ 
ty (PhD age zero to five years). Beginning with 50 additional 
grants, the program should grow by 150 in five years. 

• Increase the CER program to $25 million per year, and 
continue at that level so that infrastructure and equipment 
for experimental computing can be established and main¬ 
tained. 

• Double funds for equipment grants immediately; 
thereafter increase them as the field expands so that more 
departments can offer realistic experimental programs. 
Develop programs for funding operating costs. 

Adoption of these recommendations will help increase 
PhD production, broaden its base, promote more research, 
and encourage more rapid staffing of currently understaffed 
departments at all levels with well-educated computer scien¬ 
tists. It will provide all scientists and engineers with a better 
education in computing and will thus raise the level of com¬ 
puting in all scientific and engineering disciplines. 

Failure to avoid the clash between growth of the field and 
lack of commensurate funding growth will lead to severe 
problems. Faculty will leave academia, and departments will 
lack the needed levels of infrastructure, equipment, and 
maintenance. CS is too young and fragile to withstand more 
pressure; it is not as robust and stable as more mature 
scientific fields. 
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increasing at a rate of 8 percent a year. Infrastructure has im¬ 
proved in many departments, and higher salaries have helped in 
recruiting new PhD’s. CS is increasingly recognized as a 
legitimate academic discipline, with a growing role to play in the 
education of all scientists and engineers. 

Undergraduate and master’s enrollments have been limited in 
some institutions in order to serve the increasing numbers of PhD 
students. With an increase from 13,000 to 28,000 bachelor’s 
degrees granted annually in a recent four-year period, the supply 
of bachelor’s graduates is coming into balance with demand, 7 
which has increased the number of well-educated students seek¬ 
ing the PhD. 

Innovative programs have helped improve the research en¬ 
vironment. For example, the NSF’s program for CER, created in 
response to the Feldman Report 1 and the Snowbird Report, 2 is 
helping 22 departments establish better experimental research en¬ 
vironments, and CER departments are becoming respectable 
places to do experimental research. Industrial equipment dona¬ 
tions for CS instructional and research labs have helped 
significantly. 

However, the CER and Presidential Young Investigator, or 
PYI, programs have affected the individual research grant pro¬ 
grams. Despite the increases in CS personnel, from 1979 to 1985 
NSF’s Division of Computer Research suffered an 8 percent net 
decline in constant-dollar funding for the research of individual 
investigators. Grants have not kept pace with inflation even 
without growth, and growth has made support for graduate 
students and for both summer and academic-year research in¬ 
creasingly difficult to obtain. Now, the CER program may be 
reduced in order to increase the individual grants program, and 
the CER-supported departments may have their major source of 
support for experimental computing reduced just when they are 
beginning to establish the infrastructure needed to run ex¬ 
perimental research programs and need further modernization 
and expansion. Expansion of experimental programs in depart¬ 
ments not yet supported by the CER program is seriously 
threatened. With tight federal and university budgets, funds and 
space to house and maintain even donated equipment and to hire 
personnel have been increasingly difficult to obtain. 

In summary, the first half of the 1980s seemed extremely 
positive for CS, with the maturing and growth of the field, the in¬ 
creased support for experimental computing, and the accompa¬ 
nying increased respect for the field. But the upbeat atmosphere 
obscured the fact that funding was not growing as fast as the 
field—and at a slower rate than in other scientific disci¬ 
plines—and only recently did the field become aware that the two 
trends of personnel growth and funding nongrowth were on a col¬ 
lision course that would have serious consequences. 

The demand for computer scientists 

The demand for computer scientists at all levels is substan¬ 
tiated by all the measures that we were able to glean from the 
literature, even ones on unemployment. For example, Vetter et 
al. 8 show a 1982 unemployment rate of 0.8 percent for male PhD 
computer specialists; for all engineers the rate was 2.8 percent, 
and the rate was above 5.3 percent for all other major academic 
disciplines. 

According to an NSF report, 9 the demand for analysts and 
programmers is expected to grow from 4.9to 5.8 percent per year. 
Regardless of the scenario, by 1987 the shortfall in supply will 
range from 15 to 30 percent, or 115,000 to 140,000 personnel. 

Hamblen 7 estimates a 1983 supply of new bachelor’s degrees in 
CS at 28,000 and a demand of 54,000 per year; corresponding 
estimates for master’s graduates were 6000 and 34,000. Supply at 
the bachelor level should meet demand in about 1988, but the 
need for master’s graduates will remain unfilled for much longer. 

Hamblen estimates supply and demand for CS PhD’s at 254 
and 1300 per year, respectively. The steady-state requirement of 
1300 may seem high, but note that math, physics, and chemistry 
have a history of PhD supply of about 700,1000, and 1600 PhD’s 
per year, respectively; that enrollment of students at all levels in 


these fields is less than that of CS; and that the industrial demand 
for PhD’s in most of these fields is less. 

Hamblen also discusses the need for staffing developing 
master’s programs with computer scientists and the ultimate need 
to replace faculty in bachelor’s programs with faculty well 
educated in CS. He estimates that only half the people currently 
staffing CS departments have a PhD and only half of these are in 
CS, the desired degree for new entry PhD’s. 

There is still demand for personnel at the research centers of the 
large computer manufacturers (e.g., IBM’s Watson and Almaden 
labs, AT&T’s Murray Hill, XEROX PARC, and DEC’S SRC and 
Western Research labs) as well as at companies like GM, GE, and 
BELLCORE and many new companies in areas such as expert 
systems and artificial intelligence. Newly formed institutes are 
hiring large numbers of PhD’s. The MCC in Austin has about 110 
PhD’s in CS and EE and expects to expand to 250; the Software 
Engineering Institute in Pittsburgh will grow to 200 scientists, 
with about 60 PhD’s; and the new Software Productivity Consor¬ 
tium in Virginia has similar goals. The new Supercomputer 
Research Center in Maryland expects to expand to 300 profes¬ 
sionals. The Strategic Defense Initiative and NSF’s own super¬ 
computer initiative will fuel explosive growth that could absorb 
all the increases in PhD production in the near future. 

Finally, the universities themselves are still expanding in CS. A 
1986 survey of 103 PhD-granting CS departments 10 shows an an¬ 
ticipated increase in faculty sizes of 45 percent in five years—from 
1741 to 2527, an average of 8 per department—and vacancies 
abound. Recently, Texas at Austin created six new chairs and 15 
new positions in CS, and the state of Maryland established a new 
Institute for Advanced Computing with 30 new PhD positions, 
connected to the CS department at the University of Maryland. 

That such growth is needed is seen in data concerning the ratios 
of students to faculty in various fields, which show that CS has far 
and away the highest student/faculty ratios of any related disci¬ 
pline (Tables 1 and 2). 

Migration from other fields is one way to meet demand. How¬ 
ever, the strong flow from math to computing specialties has sub¬ 
sided, and by 1983 there was no longer a significant excess of 
math PhD’s to be employed in CS." A NSF report, 9 among 
others, predicts that by 1987 migration will be only 11 percent of 
the supply, partly because of the need for more specialized train¬ 
ing in CS. The CS PhD is now the degree of preference for new 
faculty. 

A federal report 12 asks that “consideration should be given to 
graduate-level programs and feeder programs [in CS], with the 
goal of at least quadrupling the number of graduates with ad¬ 
vanced degrees [in CS] within a decade.” It states that “the in¬ 
creasing number of commercial successes in the field will create 
attractive opportunities to drain away both scientific personnel 
and funding from basic research areas, which could lead to an 
overall decline in the rate of progress in the field and divert new 
graduates away from academic careers.” 

General growth in computer science 

Growth of scientific and engineering personnel is discussed in 
references 7, 8, and 9. Vetter et al. 8 show that, in 1982, 299,000 
computer specialists were employed in the United States. In 1982, 
this total nearly equaled the combined total of all employed 
physical scientists, mathematicians, and statisticians; exceeded 
the total of all social scientists; and approached the combined 
total (337,000) of all life scientists. 

Table 3 shows the growth of graduate departments in PhD- 
granting institutions in several areas. The number of graduate de¬ 
partments in science and engineering peaked in 1980 and has since 
been declining. In the same period, the number of CS depart¬ 
ments increased 60 percent and CS graduate-student enrollment 
doubled. 

From 1980 to 1983, full-time graduate-student enrollment in 
CS departments increased at an annual rate of 19 percent in PhD- 
granting institutions and a remarkable 36 percent in masters- 
granting institutions. Of the broad disciplinary areas, only engi- 
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Table 1. Bachelor degrees awarded and full-time faculty, all Table 2. Full-time faculty and graduate students, PhD- 

institutions, 1983. granting institutions and departments only, 1983. 


Field 

Degrees 

Faculty 

Ratio 

Field 

Students 

Faculty 

Ratio 

CS 

25,000 

2.60Q 

9:1 

CS 

9,300 

1,500 

6:1 

EE 

18,000 

3,700 

5:1 

EE 

12,800 

3,100 

4:1 

All Eng. 

73,000 

34,000 

2:1 

All Eng. 

54,000 

14,000 

4:1 

Chemistry 

11,000 

6,000 

2:1 

Chemistry 

14,500 

4,300 

2:1 

Math & Stat. 

12,600 

11,000 

1:1 

Physics 

9,300 

4,200 

2:1 

Physics 

3,800 

5,300 

0.7:1 

Math & Stat. 

10,300 

6,400 

1.5.1 


fable 3. Growth of graduate departments in 

PhD-granting institutions. 




Year 

Eng. 

Phys. Sci. 

CS 

Math. Sci. 

No. of grad, depts. 

1976 

1,004 

506 

91 

310 


1983 

1,062 

520 

146 

333 

No. grad, students 

1976 

36,231 

21,590 

4,283 

10,281 


1983 

53,553 

24,476 

9,258 

10,323 


Table 4. PhD production (computing theory was counted in 
mathematics). 




Phys. 

Comp/inf 


Comput. 

Year 

Eng. 

sci. 

sci. 

Math 

theory 

1977 

2643 

3424 

31 

933 

101 

1978 

2423 

3234 

121 

838 

55 

1979 

2490 

3320 

210 

769 

25 

1980 

2479 

3149 

218 

744 

13 

1981 

2528 

3210 

232 

728 

16 

1982 

2646 

3344 

220 

720 

11 

1983 

2780 

3437 

286 

701 

12 

1984 

2915 

3459 

295 

699 

13 

1985 
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neering, with respective annual increases of 9 and 15 percent, 
experienced gains that were in any sense similar. Since CS is often 
housed in engineering, much of the gains in engineering were due 
to gains in CS and EE/CS. Although reliable statistics on faculty 
growth in science and engineering are difficult to come by, indica¬ 
tions of personnel growth at universities are available from vari¬ 
ous NSF sources. CS grew between 13 and 22 percent per year 
from 1980 to 1984; engineering between 3 and 10 percent per year; 
and no other major area experienced significant growth. In ana¬ 
lyzing data for 1983, Vetter et al. 8 conclude that increases of per¬ 
sonnel in CS of 20 percent, and engineering of 10 percent, were 
primarily responsible for overall 1982-83 growth in science and 
engineering. 

PhD production in CS. Perhaps the most critical data for es¬ 
tablishing future growth of academic disciplines are PhD produc¬ 
tion, for the majority of new researchers and faculty are new 
PhD’s. In CS, increased PhD productivity is essential if we are to 
fill existing academic and industrial positions and if our country is 
to maintain its current intellectual leadership in computing. NSF 
data, several studies we have taken, and a new survey of 103 PhD- 
granting CS departments, 10 lead us to believe that we have begun 
a period of significant growth in PhD productivity. The following 
is a summary of our findings: 

• Table 4 shows a compound yearly increase of 8 percent in 
PhD production in the period 1980-84. (The source of the data is 
the Feldman Report, 1 except for the 1985 data, which come from 
reference 10. Other reports (e.g., reference 11) show a slightly 
lower growth rate.) 

• The first nine departments to hold grants in NSF’s CER pro¬ 
gram reported to us a 68 percent increase in the number of 
students passing PhD-qualifying examinations from 1978-80 


(just before the CER program was in effect) to 1983-85, an in¬ 
crease of over 13 percent per year. Based on NSF data, PhD pro¬ 
duction in CER departments is increasing at a rate double that in 
the other, less well-equipped, departments. 

• In a newer survey, with 36 departments responding, every 
grouping of departments by ranking outside the top four showed 
increased rates of qualifying-exam passage of 74-113 percent for 
1980-84, with the CER departments showing the highest ratios of 
exam passage to faculty and the lowest graduate student support 
per faculty. 

• In 1985, 103 PhD departments produced 325 PhD’s 10 and 
expected to produce 498 in 1986 (375 is more realistic). Seven hun¬ 
dred fifty-five graduate students passed their qualifying exams. 
The 103 departments admitted 1177 new PhD students; if one- 
half receive their PhD’s by 1992, we will be close to a 600 PhD- 
per-year rate. 

• CS is a remarkably young field, with few people over 50. 
Hamblen 7 estimates that for every 1000 PhD-level positions in 
the field, only 19 retire or die, and only 16 out of 1700 PhD faculty 
did so in 1986. 10 For the next 15 years, an increase in PhD produc¬ 
tion should translate directly into a net increase in the pool CS 
researchers. 

We conclude that the nation’s leading CS departments have 
successfully “filled the pipeline” with increasingly high-quality 
graduate students; a base for significant increase in PhD produc¬ 
tion has been established. Given adequate funding to support 
PhD-related research, the national yearly increase in CS PhD’s 
could be 10-12 percent. 

Federal funding in the past. Federal funding of basic research 
in CS has increased significantly since the late 1970s, but it has not 
kept pace with the growth of the field. Table 5 shows that from 
1978 to 1985 NSF funds for basic research in CS grew at a rate 
comparable to that for math and less than that for engineering, 
despite the fact that neither math nor the physical sciences ex¬ 
perienced significant net growth in personnel during this period 
and despite the fact that the personnel growth rate for CS was 
consistently about double that for engineering. 

Furthermore, in recent years federal funding for basic research 
in CS has fallen even further behind. For 1983-85, growth in 
NSF’s CS funding was only 6.7 percent annually, far less than the 
growth of personnel discussed in the section General Growth in 
Computer Science. In spite of the higher growth rates in academic 
personnel, CS has nearly the lowest growth in NSF funding of any 
major area supported by NSF, and each major area expects 
significantly higher percentage increases in the future. 

Somewhat paradoxically, the use of CS funds within the NSF 
to support the CER and PYI programs has resulted in a net 
constant-dollar decrease in funding available for individual pro- 
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Table 5. Percent increases in basic-research federal funding. 


Total fed. 

NSF 

Total fed. NSF 


funding 

funding 

funding funding 


1978-85 

1978-85 

1982-85 1982-85 

CS* 

90% 

56% 

7.1% 12.3% 

Eng. 

65% 

61% 

10.5% 14.5% 

Phys. Sci. 

38% 

33% 

9.4% 12.2% 

Math & Stat. 

60% 

54% 

10.5% 15.3% 

* The growth of 90% for CS in 1978-85 is 

overstated, because of shifts in reporting 

in 'he late 1970 s 

. For example, some CS-research support recorded under math was 

transferred to CS during this time. See Appendix A and the full report for more details. 


Table 6. Support (from all sources) of full-time graduate 
students in PhD institutions, 1983. 

No. full-time No. supported Percent 


Field grad students grad students supported 


CS 

9,300 

4,200 

45% 

Eng 

54,000 

31,000 

60% 

EE 

12,800 

7,300 

60% 

Math & Stat. 

10,300 

7,800 

75% 

Physics 

9,300 

8,100 

90% 

Chemistry 

14,500 

13,500 

95% 


Table 7. Estimated budget authorizations in millions of 

dollars for 1985 and 1986. 



Field 

1985 

1986 

% increase 

Eng 

150.0 

170.1 

13.4% 

Physics 

115.6 

123.4 

6.7% 

Chemistry 

87.4 

93.5 

7.0% 

CS 

39.1 

41.7 

6.6% 

Math sci. 

47.5 

54.7 

15.2% 

Materials res. 

107.1 

115.0 

8.0% 


posals, just at a time when programs such as CER have stimulated 
a healthy increase in PhD productivity and experimental work. 
Badly needed growth in the field has been successfully stimulated, 
but at the direct expense of the basic support needed to sustain 
research at its required levels. 

An example of the problems facing CS is given in Table 6. If CS 
is to achieve the levels of PhD production of established fields like 
mathematics, physics, and chemistry, it must have comparable 
support for research. 

Prospects for federal funding 

In the second half of the 1980s, no overall increases in 
constant-dollar federal funding for basic research are expected, 
and CS is now receiving relative budget increments smaller than 
those of other science and engineering areas. This view is sup¬ 
ported by Table 7, which gives estimated budget authorizations in 
millions of dollars for 1985 and 1986. 

Furthermore, as the budget process has proceeded under the 
influence of Gramm-Rudmann, these proposed figures have 
proved to be optimistic, and CS expects little or no increases in basic 
research funding in the next few years, whereas other areas do. 


T he universities have been funding CS growth at rates 
significantly higher than in any other major discipline. But 
national funding policy has favored the growth of basic 
research in CS at a rate no greater than that of other scientific, 
mathematical, and engineering disciplines. In fact, federal budget 
projections allow for no real growth in constant-dollar funding 
for CS. The effects of low growth rates in federal funding for 


universities’ basic research in CS are already being felt. First-rate 
assistant professors in well-ranked CS departments are finding it 
increasingly difficult to get well-reviewed research proposals 
funded. In 1984-86, even senior researchers with outstanding 
research proposals have been notified of major funding cutbacks 
and delays in funding. 

University funding policies are on a collision course with 
federal funding patterns. With no policy changes, we expect 
ultimate failure in the universities’ efforts to attract and hold 
high-quality computer scientists for academic careers and the ar¬ 
rest of growth of academic CS. Just as in the late 1970s, the late 
1980s will witness the departure of our best and most mobile com¬ 
puter scientists and graduate students for industrial careers. In¬ 
evitably, the universities will be unable to maintain the centers of 
academic excellence in CS that have been so carefully developed 
during the past five years. In light of the documented national 
need for significant expansion of graduate CS programs and the 
ability of adequately funded programs to increase PhD produc¬ 
tion significantly, a new funding policy for basic research and 
PhD education is needed. We can only hope that universities, in¬ 
dustry, and governments will work together to implement the 
recommendations given in the executive summary. 
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Appendix A. 

Problems with data in CS 

There are unique difficulties in interpreting CS data. For CS, the past 
15 years have been a period of transition. As the field has grown, CS has 
become a separate category in statistics for various agencies, rather than 
being counted as a part of math or EE. The process is continuing. Fur¬ 
thermore, just as there was initially a tendency to count CS as part of 
math, there is now a tendency to count applications of computers and 
computer-science methods as CS. 

NSF’s count of PhD’s in CS prior to 1980 is one source of confusion, 
because at one point in the 1970s Computing Theory PhD’s were 
switched from math to CS. Fortunately, the Taulbee surveys 11 have 
helped us straighten out this problem. A more systematic bias in federal 
data-gathering has been to count practicing CS personnel in EE/CS de¬ 
partments under EE, even though substantial CS funding is in leading 
EE/CS departments like Berkeley and MIT. 

A damaging confusion arises in the differences between reported feder¬ 
al expenditures and obligations. NSF reports that, according to univer¬ 
sity-supplied figures, in 1983 the six highest expenditures of federal re¬ 
search and development funds in CS were at Johns Hopkins ($34.3 
million), CMU ($10.8 million), New Mexico State ($8.4 million), Stan¬ 
ford ($7.9 million), MIT ($7.1 million), and Georgia Tech ($3.8 million). 
However, the funds at Johns Hopkins, New Mexico State, and Georgia 
Tech were not spent in CS departments, where the core of the discipline 
and PhD production are nurtured, but instead, we think, in the Johns 
Hopkins applied physics lab, the New Mexico State physical sciences lab, 
and the Georgia Tech Research Institute. 

Because of poor control of university reporting, in 1983 CS was in the 
anomalous position of having university-reported expenditures in CS re¬ 
search and development of $177 million and federally reported obliga¬ 
tions for basic research of only $53 million! No other discipline exhibits 
this sort of discrepancy. 

Reporting funds spent in the nation’s new supercomputer and scientif¬ 
ic computing efforts as support of CS will introduce large distortions. The 
NSF’s Office of Advanced Scientific Computing has a budget equal to 
that of the Division of Computer Research, yet only a fraction is spent for 
research in CS. Also, other federal agencies are making large expendi¬ 
tures for supercomputers. Misinterpretation of this funding alone could 
result in a 100 percent error in the data on CS, and yet this distinction is 
not well understood outside the CS community. 

Another problem is the identification of federal funds for basic re¬ 
search (the mainstay of any research department and of PhD production) 
and federal and industrial funds for development and applied research. 
Development and applied research, although useful, often does not serve 
the primary research role of academic departments and is frequently best 
performed in labs not directly associated with academic departments. 
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Gilnternational87 


The Computer Graphics Society (CGS) is pleased to an¬ 
nounce CG International ’87" as the 5th International 
Conference on Computer Graphics in Japan, organized by 
CGS and now sponsored by the Hightechnology Institute. 
CG International '87 is dedicated to computer graphics, 
and focuses on this technical area by bringing researchers, 
artists, vendors and users together in technical sessions and 
art shows. Novel ideas will be presented, new products/art 
works introduced and a comprehensive understanding of 
the state-of-the art developed. This serves researchers, 
artists, engineers, managers and supervisors in all indus¬ 


tries. You will be able to reach the key people in the inter¬ 
national computer graphics communities at this time and 
also expand your market worldwide. Participation in CG 
International ’87 by a non-CGS member automatically 
entitles that person to CGS membership for one year. CGS 
members’ privileges include 6 isssues of the CGS official 
journal “The Visual Computer: An International Journal of 
Computer Graphics” and discount on the registration 
fees for CGS sponsored conferences, tutorials, shows and ex¬ 
hibitions. This is an opportunity you cannot afford to miss. 


Call for Papers 


High quality original research papers in the following 
three categories are invited: 

Category 1 Academic Research Ropers 

Neu: theories and experimental results related 
to computer graphics and visual information 

Category 2 Computer Art Papers 

New concepts, methods, software tools and 
devices for the production of novel and high 
quality art works by computers. The papers 
should be accompanied by samples of the 

as positive color film slides. The art works 
may also be exhibited at the conference at 
the exhibitor's cost. 

Category 3 Industrial Product Papers 
New technology, concepts and applications 
leading to industrial products related to 
computer graphics and visual information 

arranged at cost. 

The topics include (but are not limited to) : 

1 Computer-Aided Design, Manufacturing 
and Engineering (CAD/CAM. CAE) 

2 Business and Management Graphics for 
Office Automation 

3 Robotics 

4 Graphics for the Entertainment Industry 

5 Computer Art 

6 Animation 

7 Graphics for Laboratory Automation 

8 Graphics for Scientific /Engineering Ap¬ 
plications 

9 Medical Graphics 

10 Architectural Graphics and Automated 
Drafting 

11 Local Area Networks for Graphical 
Communications 


12 Graphic Data Base Management 

13 Computer Cartography 

14 Graphic Languages/User Interfaces 

15 Design Automation 

16 Computer Graphics Development 

17 3D Solid Modeling 

18 Image Processing 

19 VLSI and Chip Design 

20 Display Technology 


Information for Authors: Papers should contain 
previously unpublished original results, new 
ideas and complete references to related 
works, and should range in length between 
5000-10000 words. The first part of each 

• title 

• a maximum 150 word abstract of the 
paper 

• a maximum 10 key words and phrases 

• author’s name(s), title, affiliation, com¬ 
plete mailing address, phone numbers, 
short biography and photo 

cepted, one of the authors will present the 
paper at CG International ’87," and the 
name of the author who is responsible for 
the inclusion of the paper in the confer¬ 
ence proceedings. Papers should he typed 


A paper lacking any of the above informa¬ 
tion will not be considered by the Program 

The accepted papers will be printed in the 
Proceedings to be published by Springer- 
Verlag, Tokyo, Heidelberg. Berlin, New 


Expanded versions of exceptionally high quality 
papers will he invited for submission for publicathn 
in "The Visual Computer: An International loornal 
of Computer Graphics" or "IEEE Computer Graphics 
and Applications" magazine. 


Deadlines: 

December 15. 1986 Initial full paper 
February 1. 1987 Authors notified of 

March 10, 1987 Camera-ready papers 
received 

Send five copies of paper to: 

CC International ’87 

Chairman of Program Committee 

Prof. Dr. Toshiyasu L. Kunii. CGS President 

< /o Department of Information Science 

Faculty of Science 

The University of Tokyo. 

Hongo. Tokyo 113, Japan 
Plume: (03) 812-2111 Ex. 4116 
Telex: UTYOINFO134853 
Fax: (03) 813-2772 


Organized by 


CG5 


Computer Graphics Society 


Sponsored by the Hightechnology Institute 


In cooperation with (tentative) 


IEEE Computer Society 


The European. 
Graphics 








Further, it may not be tightly linked to PhD education. A federal panel 
report 12 points out the need to quadruple the number of graduates with 
advanced degrees, but fails to discuss how well federal funding is lever¬ 
aged to increase PhD productivity. According to this report, 12 from 1983 
to 1985 the NSF accounted for less than 30 percent and DoD for 60 per¬ 
cent of the federal funding of CS research and development in univer¬ 
sities. In that period, federal expenditures in CS increased from $173.4 to 
$298.3 million, while the amount spent in universities increased from 
$112.9 to $180.0 million. The federal panel report 12 and the more stan¬ 
dard source, NSF Report NSF84-336, agree that the largest increases in 
federal funding for CS research and development came from DoD. 

At first glance, the federal panel’s report 12 indicates fairly large in¬ 
creases in CS research funding. However, the only significant increases in 
constant-dollar funding by DoD for CS, $67 million, are in “special ap¬ 
plied research projects in mathematics and CS,” presumably in DoD’s 
Strategic Computing Initiative, or SCI. The major thrust in SCI is over, 
and SCI funding is expected to decrease in the next few years. Reduced 
DoD funding would negatively impact the research capabilities of the top 
four CS departments (see Appendix B). Given these facts, we believe that 
the favorable increases for funding of research in CS reported in reference 
12 should not be accepted without a more careful analysis of the data and 
of the types of academic work actually supported. 

Appendix B. 

Funding in CS departments 

In November 1985, our committee surveyed funding in the roughly 100 
PhD-granting CS departments. Fifty-six departments responded to the 
survey (see reference 13 for the list of responding departments). The 
response was fairly uniform with respect to departmental ranking as pre¬ 
sented in a report published by the National Academy Press, 14 but 
strongly skewed toward a higher response rate from highly ranked 
departments. 

Briefly, Table B-l shows strong CS support by DoD for the top four 
universities and much less support for the rest. A history of strong DoD 
research funding has played a key role in enabling the top four to estab¬ 
lish highly successful labs, but has done little to create broad-based 
PhD production. 

With 56 of 100 departments reporting, we estimate that the top four de¬ 
partments account for one-eighth of all students now passing qualifying 


exams. Their superior labs and research environments make their PhD 
students highly sought after. At the same time, we estimate that the de¬ 
partments ranked 5-12 account for nearly one-fourth of the students 
passing qualifying exams. 

The greatest rates of increase in passage of qualifying exams are com¬ 
ing outside the top four. This, together with the astonishing drop in fund¬ 
ing per student below the top four, suggests that the departments ranked 
5-12 are now seriously overcommitted to support of PhD students. Also 
many departments not ranked among the top 36 lack adequate resources 
to support PhD research programs. 

NSF funding is concentrated outside the top four and is fairly 
smoothly distributed among departments, but weighted toward the 
highly ranked ones. Such a distribution probably has maximal impact 
on PhD productivity. 

In summary, DoD funding is not well correlated with the rapid expan¬ 
sion in PhD production. Since the only significant federal funding in¬ 
creases are coming from DoD (see Appendix A), federal funding in¬ 
creases are not fueling broad-based PhD production. 


Table B-1. Distribution of reported federal research funding, 
1985 (excluding equipment grants). 



Let Us Place You 

—- IN A 

BETTER JOB NOW 


Put our 20 years of experience placing technical professionals to 
work for you. Client companies pay all fees, interview and relo¬ 
cation costs. You get our expert advice and counsel FREE. 
Nationwide opportunities in Communications, Defense, Intelli¬ 
gence, Computer, Satellites, and Aerospace Systems. 

We are seeking individuals with experience and interest in one 
or more of the following areas: 

• Software Configuration Management 

• Data Base Design and Development 

• Distributed System Design and Development 

• VAX Software Development Under VMS 

• IBM 4341 Software Development 

• FORTRAN and MACRO Programming 

• Military Standard Systems Design and Development 

• Local Area Networks 

• Color Graphics Display Software Design 

• Rapid Prototyping 

• Software Quality Assurance 

• Artificial Intelligence 

• Test Planning and Testing 

• Verification and Validation 
Salaries range from 
$30,000-$75,000 plus. 

U.S. citizenship 
required. EBI/SB1 
desirable. Let us place 
you in a better, more 
rewarding job . . . now. 

Send your resume in 
confidence to: 

Dept. CA-IC 

Wallach . . . Your Career Connection 
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Conference and Professional Education Programs 

November 2-6,1986 • INFOMART* • Dallas, Texas 

FALL JOINT COMPUTER CONFERENCE 

Jointly sponsored by ACM and IEEE Computer Society 


Choose from over 120 sessions and courses—Register today! 
Concurrent with a major exhibition— 


Save up to $185 
when you pre-register! 


We’re not just talking 
about professional leadership 
in the 1990’s — 

We’re making it happen! 

Join us at the world's first information processing market center— 
INFOMART 

A Landmark Event! 

• The breadth and depth of FJCC’s content surpasses that of any conference held in 
the last decade! 

• Nine conferences will proceed simultaneously at FJCC—each of which is a front¬ 
line, major event on its own. 

• The top, key people in all nine conference areas have agreed to be presenters. 

• Daily Keynote speakers feature Nobel Laureates 

• In-depth educational and hands-on sessions via access to selected INFOMART 
showrooms and Exhibitor Technical Forums. 


Over 150 exhibiting companies will highlight the technology embedded in 
their key products. 

Observe two world-class Chess Tournaments—the 17th North American 
Computer Chess Championship (NACCC), and the 6th World 
Microcomputer Chess Championship (WMCC). 
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Artificial Intelligence (AI) 


Building Expert Systems Workshop —Sun. # 390 or Mon. H 395 
Instructor: John D. McGregor, Dept, of Computer Studies, 

Murray State U. 

Hands-on experience with an expert system development system 
—knowledge representation—evaluation criteria 

Knowledge-Based Expert Systems —Sun. It 320 or Mon. # 325 
Instructors: Lois Boggess and Julia Hodges, Dept, of Computer Science, 
Mississippi State U. 

Concepts and Techniques of AI and Data Base Management Systems 
(DBMS) as they interact in knowledge-based expert systems. 

Architectures for A! Applications —Sun. # 380 or Mon. # 385 
Instructor: Benjamin W. Wah, Dept, of Electrical and Computer 
Engineering, U. of Illinois at Urbana-Champaign. 
Computer-design of support systems for AI applications—limitations in 
current techniques—technologies for implementation. 

Natural Language Processing —Sun. # 315 

Instructor:. Michael Lebowitz, Dept. Computer Science, Columbia U. 
Basic methods of Natural Language Processing—syntactic processing- 
semantic processing—generation techniques—Natural Language 
Processing generation in practical systems. 

Machine Learning —Mon. It 950 

Instructor: Michael Lebowitz, Dept, of Comp. Sci., Columbia Univ. 
Study of systems that automatically extend their knowledge or improve 
performance over time—application of learning techniques—intelligent 
diagnostic and information systems—expert system development. 


Speech Recognition: From Isolated Digits to Natural Language 
Dictation— Sun. # 830 

Instructor: Paul Bamberg, Prin. Scientist, Dragon Systems. 

Technology of speech recognition and its applications—demonstrations— 
hands-on experiences—isolated-word versus connected-speech 
recognition. 

Computer Vision from an A! Perspective —Mon. H 940 
Instructors: John Kender and Takeo Kanade, Dept. Computer Science, 
Columbia U. 

Expert vision systems—knowledge representation—indexing schemes— 
robotic navigation. 

PROLOG & Knowledge Info. Processing —Sun. H 370 or Mon. H 375 
Instructor: Douglas DeGroot, V.P. (R&D) Quintus Computer Systems 
Introduction and evaluation of PROLOG in expert system development 
and other AI applications—control component—application domains— 
writing PROLOG programs—exploring a simple PROLOG interpreter. 

*AI Programming and Environments —Sun. and Mon. # 340 
Instructor: Harlan H. Black, Computer Scientist, U.S. Army, 

Communications/Electronics Command (ARES Project). 
Overview/analysis of LISP development and application environments— 
rule-based applications—hands-on experience with an expert system 
development tool—reading and developing LISP code. 

* Two day course 


Computer Design 


VLSI Circuit Layout —Sun. # 120 or Mon. # 125 

Instructors: T.C. Hu, E.E. and Computer Science Dept, of UC San Diego 
and M.T. Shing, Computer Science Dept, at UC Santa 
Barbara. 

Review of current literature and algorithms on layout and compacting 
PLA, Weinberger’s Arrays—design of VLSI chips—CAD (computer- 
aided-design) tools. Attendees are encouraged to submit a problem to the 
instructors 15 days prior to the conference. 

RISC Architecture —Sun. # 140 or Mon. # 145 

Instructor: V.M. Milutinovic, School of Elec. Engr., Purdue U. 

Reduced Instruction Set Computer (RISC) processors and related 
topics—advantages and drawbacks—case studies included (UC Berkeley 
RISC, Stanford MIPS, Ridge, Pyramid, etc.). 


Concurrent Processing Architecture —Sun. It 160 or Mon. H 165 
Instructor: Philip M. Neches, founder, and chief scientist of Teradata 
Corp. 

Reviews of concurrent processing-computer systems—computing elements 
functioning in parallel—commercialization of concurrent processing 
technology. 

*Fault-Tolerant Systems: Principles & Examples —Sun. and Mon. #150 
Instructors: Dhiraj Pradhan and Adit Singh, Dept, of Electrical and 
Computer Engineering, U. of Massachusetts at Amherst. 
Factors that cause system failure—hardware and software to protect the 
systems—design techniques to enhance testability—models for evaluating 
effectiveness—case studies of several systems. 

* Two day course 


Programming Systems 


The UNIX Operating System —Sun. # 580 

Instructor: John Carson, Dir. of the Information Systems Program—The 
George Washington U. 

Introduction to the UNIX operating system—architecture and capabilities 
of the operating system—capabilities demonstration. 

The “C” Programming Language —Mon. # 585 
Instructor: Alan Feuer, Vice President for Software Development, 
Catalytix Corporation of Cambridge, Mass. 

Introduction to the C language through examples and exercises. 

Parallel and Concurrent Programming in Ada® —Mon. tt 930 
Instructor: George W. Cherry, President of Thought**Tools 
The effective use of Ada® multitasking through examples and case studies. 


* Hands-on Ada ®—Sun. and Mon. # 560 

Instructor: Helmut E. Thiess, Computer and Information Sciences 
Department at Towson State University. 

The use of the Ada®programming language in a programming support 
environment. The attendees will gain modest familiarity with Ada® for use 
in their workplace, and have the opportunity to evaluate Ada® by hands- 
on building of software. 

AppTn. Generators/4th Generation Languages —Sun. It 650 or Mon. H 655 
Instructors: Donald Chand, Dept, of Computer Information Systems, 
Bentley College and Sri Raghavan, Wang Institute. 
Framework for understanding, studying and evaluating the AG/FGL, 
phenomenon—a taxonomy for classifying the approaches. 


"Two day course 
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Software Engineering 

DoD Standards for Software System Develop.— Sun. # 520 or Mon. # 525 
Instructor: Lee Cooper, Chairman, The Joint Logistics Commander’s 
Computer Software Management Subgroup. 

The software development cycle defined in DoD-STD-2167 in the context 
of the defense systems life cycle; the software-related changes to MIL- 
STDs 483, 490, and 1521; and the consolidated set of 24 Data Item 
Descriptions (DIDs). 

Evaluating Ada® Environments— Sun. # 570 or Mon. # 575 

Instructor: Nelson Weiderman, on leave from Computer Science faculty, 

U. of Rhode Island as co-principal investigator on a project to 
evaluate Ada® programming environments. 

Systematic methodology for evaluating software development 
environments for the Ada® programming language. 

Software Testing —Sun. # 630 

Instructor: William Hetzel, A principal of Software Quality Engineering. 
Software testing in terms of what are good software testing practices and 
how should testing be structured and managed—key management and 
technical issues—software testing practices. 

The Road to Software Quality —Mon. # 635 

Instructor: David Gelperin, President of Software Quality Engineering. 
What is good software? How do we verify its quality? Who is responsible 
for that quality? 

Functional Test —Sun. # 530 or Mon. # 535 

Instructor: William E. Howden, Comp. Sci. faculty, UC San Diego. 

Basic ideas of functional testing and analysis—tools and techniques to 
support function test. 

Tools <fc Techniques for Life-Cycle Software Quality Assurance — 

Sun. # 510 or Mon. # 515 

Instructor: Alfred R. Sorkowitz, Comp. Scientist, Dept, of the Navy. 
Commonly available tools and techniques for developing and maintaining 
quality software as well as increasing productivity of software 
professionals. 

Computer Engineering 

* Intro. to Microcomputer Interfacing— Sun. and Mon. # 920 

Instructor: Peter R. Rony, Dept, of Chem. Engr. Virginia Tech. 

Introduction to fundamental microcomputer hardware concepts— 
interfacing key integrated circuit-latches, decoders, and three-state 
buffers—to a Z80 microcomputer. 

Hands-on Robotics —Sun. # 240 or Mon. # 245 

Instructor: Richard D. Amori, Comp. Sci. Dept., East Stroudsburg U. 

Basic robotics concepts and application to industrial problems—Robot 
components, hardware and software—hands-on experience using a lab 
version of a modern industrial robot, RHINO XR2. 

User Engineering and Active Prototyping —Sun. # 840 or Mon. # 845 
Instructors: Larry L. McLaughlin, TRW User Engineering R&D 

Activities, Lance Valt and Scott Overmyer, TRW User 
Engineers. 

Strategy for rapid prototyping—multi-disciplinary techniques and tools— 
making complex decisions and solving problems—engineering of human- 
computer systems. 

* Two day course 

Modeling and Measurement 

* Performance & Reliability Models of Computer Systems— Sun. and 

Mon. # 430 

Instructors: K.S. Trivedi, Computer Science Dept., Duke U. and Dr. 

Robin Sahner, staff member at Gould Inc. 

A workshop to gain training, experience and insight into applying 
modeling techniques to program performance analysis and program/ 
system reliability analysis. The SHARPE tool is used for hands-on 
performance and reliability modeling of computer systems. 

Software Cost Estimation and Control —Mon. # 455 

Instructor: Barry W. Boehm, Chief Engr. TRW Software Devel. Div. 
Techniques for estimating and controlling the costs of software 
development and maintenance—software project planning and control 
techniques; estimating software development costs; factors influencing 
software costs; and improvement of software productivity. 

* Two day course 

Computing Issues 

Network Management Control System —Sun. # 210 

Instructors: Jerry Cashin, with over 15 years of experience in data 

communications, network topologies, and configuration 
evaluation and Satish Nandapurkar, involved in network 
design for the U.S. Air Force. 

Review of the history, principles, techniques, and raison d’etre for 

Network Management Control Systems—systems and software for control 
of computer networks. 

End-User Training: The Microcomputer Market Weak Link —Mon. # 720 
Instructor: Susan Helms, Comp. Sci. faculty, Hardin-Simmons U. 

Practical training to achieve a growth market—selecting and preparing 
trainers—components to be included in training—choices of instructional 
media—cost considerations in training—training evaluation. 

Graphic Design for Computer Graphics —Sun. #610 

Instructor: Aaron Marcus, Aaron Marcus and Associates. 

Concepts, principles, methods and examples of screen, slide, and page 
design—use of typography, symbol and icon systems, color, spatial 
composition, animation, and sequencing in such applications as data- 
driven charts and forms, user interfaces, documentation, and program 
visualization. 

Cultivating & Enhancing Creative Abilities —Sun. # 810 or Mon. # 815 
Instructor: Dempsey George, an authority on Creativity, The Future, and 
Networking. 

Stir and cultivate creative potentials—learn “how to create new ideas,” 
solve problems, make decisions, convert stress and worry into creative 
energy. Develop more self-confidence, and motivate yourself. 

















ROOM ROOM ROOM ROOM ROOM ROOM ROOM ROOM ROOM 


FALL JOINT COMPUTER CONFERENCE—2-6 NOVEMBER 1986 


ii .1 lull La 


X 


o 



.fill B i !J 


y 







jglll! 



3 

iii 

ii 

m 

|li 


MM 

h d I 

yy 

B U 


□1 

MM j 

Ld &J 

it* 

k 


lull 

iiii 

ii* j 



ii 

M 

h- 


i« 

V* 

gill 


iii 

ill 

iii 

ill 

aSi 

iii 

Mi 

i&i \ 

iii 

ii 

in 

ills! 

III 

■Mi 

i* 

ii 

M 

Cr 

\j% 


c« 

OO 

a 

<3\ 


I 1 


i I 

















































































Artificial Intelligence (AI) Supercomputing (SC) 


AI-l: Artificial Intelligence Technology 

Chair: Dr. Elaine Kant, Schlumberger-Doll Research Center 

Session 1: “Design Issues and Practice in AI Programming’’(Rm. 2-H) 

Session Chair: Nancy Martin, Softpert Systems Inc. 

Elliot Soloway, Yale U.; B. Chandrasekaren, Ohio State U.; Carl 
Werowinski, Applied Expert Systems Inc. 

AI-2: Computer Vision 

Chair: Prof. John Kender, Columbia U. 

Session 1: “Approaches to Low and Middle-Level Vision” (Rm. 5-1) 
Session Chair: Prof. John Kender, Columbia V. 

Dr. Thomas Binford, Stanford U.; Prof. J.K. Aggarwal, U. of Texas at 
Austin; Dr. Robert Haralick, Machine Vision International 
Session 2: “Model-Based High-Level Vision” (Rm. 6-1) 

Session Chair: Prof. John Kender, Columbia U. 

I. Abdou and N. Dusaussoy, U. of Delaware; S.K. Chang and E. Jungert, 
Illinois Institute of Technology; L. Matthies and S.A. Shafer, Carnegie 
Mellon U.; S. Srihari, State U. at Buffalo 
AI-3: Robotics 

Chair: Prof. Richard Paul, University of Pennsylvania 
Session 1: “Robot Perception" (Rm. 6-G) 

Session Chair: Prof. T. Kanade, Carnegie Mellon U. 

R.L. Andersson, AT&T Bell Labs.; Y. Goto, et al. , Carnegie Mellon U. 
Session 2: “Task-Level Robot Programming” (Rm. 7-G) 

Session Chair: Prof Tomas Lozano-Perez, MIT 

M. T. Mason and R.C. Brost, Carnegie Mellon U.; V. Nguyen and W.E. 
Grimson, MIT 

Session 3: “Real-time Robot Programming” (Rm. 8-G) 

Session Chair: Dr. Russell Taylor, IBM T.J. Watson Research Center 
L. Nackman, et a!., IBM T.J. Watson Rsch. Ctr.; J.B. Chen, et al., 
Stanford U.; R. Gaglianello and H. Katseff, Bell Labs.; R. Paul and H. 
Zhang, U. of P. 

AI-4: Rule-Based Systems 

Chair: Prof. David Rine, George Mason U. 

Session 1: “Software Engineering for Rule-Based Systems” (Rm. 5-C) 
Session Chair: Dr. David Rine, George Mason U. 

Dr. Jorge Diaz-Herrera, George Mason U.; Dr. Harry Tennant, Texas 
Instruments; Drs. Ishibashi, Chikayama, Sato, Sato and Uchida, ICOT 
Rsch. Ctr.; R.J.K. Jacob and J.N. Froscher, Naval Rsch. Lab. 

Session 2: “Knowledge Engineering” (Rm. 6-C) 

Session Chair: Dr. Richard Wexelblat, Phillips Laboratories 
Dr. Paul Benjamin, Phillips Laboratories; Dr. Christina Jette, 
Schlumberger Well Services; Dr. Steve Pollit, Digital Equipment 
Session 3: “Rule-based Models and Applications” (Rm. 7-C) 

Session Chair: Dr. Elaine Kant, Schlumberger-Doll Research Center 

T. Blaxton and B. Kushner, BDM Corporation; Q. Chen, Beijing 
Research Institute of Surveying and Mapping; M. Ali and E. Washington, 

U. of Tennessee; K. Yoshida, et al., Hitachi, Ltd. 

Session 4: “PROLOG and Frame-Based Methods” (Rm. 9-C) 

Session Chair: Dr. Kenneth De Jong, George Mason U. 

H.H. Chen, National Taiwan U.; K. Magel, North Dakota State U.; N. 
Tamura, Japan Science Institute, IBM Japan 
AI-5: Natural Language Processing 

Chair: Prof. Robert Wilensky, U. of California at Berkeley 
Session 1: “User Interfaces” (Rm. 1-1) 

Session Chair: Prof. Robert Wilensky, U. of California at Berkeley 
Prof. Kathleen R. McKeown, Columbia U.; Dr. Paul S. Jacobs, General 
Electric Corp., Research and Development; Dr. Phillip J. Hayes, Carnegie 
Group Inc.; Dr. Paul Martin, SRI-Artificial Intelligence Center 
Session 2: “Natural Language Processing” (Rm. 2-1) 

Session Chair: Prof. Richard Granger, UC at Irvine 

N. Sondheimer, USC ISI; K. Eiselt, UC at Irvine; R. Cullingford; Georgia 
Tech; G. Cottrell, UC at San Diego 

Session 3: “Problems And Prospects Of NLP” (Rm. 3-1) 

Session Chair: Prof. Phillip J. Hayes, Carnegie Group Inc. 

Gene Charniak, Brown U.; Dave Waltz, Thinking Machines; Jerry Hobbs, 
SRI; Gary Hendrix, Symantec 


SC-1: Parallel Computation 

Chair: Prof. Kai Hwang, U. of Southern California 
Session 1: “Parallel Processing for AI”(Rm. 1-D) 

Session Chair: Prof Kai Hwang, U. of Southern California 
D.I. Moldovan and C.l. Wu, U. of Southern California; S. Morton and F. 
Tse, ITT-Advanced Technology Center; M. Imai, et al., Toyohashi U. of 
Technology; G.J. Li and B.W. Wah, U. of Illinois at Urbana 
Session 2: “Parallel Algorithms for Supercomputing” (Rm. 2-D) 

Session Chair: Prof. Benjamin Wah, U. of Illinois at Urbana 

P.S. Tseng, U. of Southern California at LA; S. Lakshmivarahan, U. of 

Oklahoma; M.J. Chung, et al., Rensselaer Polytechnic Institute 

SC-2: High Performance Numerical Architectures 
Chair: Dr. Cleve Moler, INTEL Scientific Computers 
Session 1: “Hypercube Computers” (Rm. 3-D) 

Session Chair: Dr. Cleve Moler, INTEL 
Dr. John Palmer, NCUBE 

SC-3: Multiprocessors 

Chair: Prof. Daniel Siewiorek, Carnegie-Mellon U. 

Session 1: “Multiprocessors I”(Rm. 4-D) 

Session Chair: Dr. Zary Segall, Carnegie-Mellon U. 

H. Muehlenbein, et al., GMD; S. Hariri and C.S. Raghavendra, USC; J. 

Herath, Keio U.-Japan 

Session 2: “Multiprocessors II” (Rm. 5-D) 

Session Chair: Dr. Pat McGehearty, Microelectronics & Computer 
Technology Corporation 

W.M. Ching and P. Bose, IBM T.J. Watson Research Center; V. Lanin 
and D. Shasha, Courant Institute, New York U. 

Session 3: “High-speed Techniques” (Rm. 6-D) 

Session Chair: Dr. William Brantley, IBM T.J. Watson Research Center 
P.C. Barr and S. Krishnamoorthy, Framingham State College; C.Y. Chen 
and J.A. Abraham, U. of Illinois at Urbana; D.J. Schanin, Infinity 
Systems. 

SC-4: Optical Computing 

Chair: Dr. C. Lee Giles, AFOSR/NE 

Session 1: “Optical Computers” (Rm. 1-A) 

Session Chair: Dr. John Caulfield, U. of Alabama 

Dr. F.J. Leonberger, UT Research Center; Dr. Alan Huang, AT&T Bell 

Laboratories; Dr. Ravi Athale, BDM Corporation 

Session 2: “New Directions in Optical Computing” (Rm. 2-A) 

Session Chair: Dr. C. Lee Giles, AFOSR/NE 

Dr. Demetri Psaltis, C.I.T.; Dr. John Neff and B. Kushner, DARPA/ 

DSO; Dr. A.D. McAulay, Texas Instruments 

Session 3: “Optical Interconnections for Computing” (Rm. 3-A) 

Session Chair: Dr. John Neff, DARPA/DSO 
Dr. Lynn Hutcheson, Cyber Optics Corporation; Dr. Alexander 
Sawchuck, USC, Image & Signal Processing Institute; Dr. D. Hartman, 
Bell Comm. Research 

SC-5: Networks 
Chair: Michael Willett 

Session 1: “Implementing A Token-Ring Local-Area Network” (Rm. 4-A) 

Session Chair: Michael Willett, IBM Corporation 

Jane Munn and Jaclyn Winkler, IBM Corporation; Jim Carlo, Claire 

Hamner, Texas Instruments; Sunil Joshi, Advanced Micro Devices 

Session 2: “Attaching to Token-Ring Local Area Networks” (Rm. 5-A) 

Session Chair: Michael Willett, IBM Corporation 

Charles Bass, Ungermann-Bass; Harry Saal, Nestar Systems; Judith 

Estrin, Bridge Communications; Howard Salwen, Proteon 

Session 3: “Managing The Integration of Voice and Data” (Rm. 6-A) 

Session Chair: William G. Hooper, Price Waterhouse 

K. Conley, Monsanto Company 







Software Systems (SS) 

SS-l: Software Engineering 

Chair: Prof. Laszlo Belady, MCC 

Session 1: “New Software Design Modes” (Rm. 3-C) 

Session Chair: Prof. Laszlo A. Belady. MCC 
Gerald Weinberg, Weinberg and Weinberg. 

Session 2: “Object-Oriented Software” (Rm. 2-C) 

Session Chair: Dr. Clarence Ellis/ Dr. Ted Biggerstaff, MCC 
Dr. Gael Curry, Sequent Computer Inc.; Ken Doyle, et al., Apple 
Computer; Prof. Alan Borning, U. of Washington; Prof. Stan Zdonik, 
Brown U. 

Session 3: “Applications of Ada to Large System Development” (Rm. 9-B) 
Session Chair: Dr. C. Robert Morgan, Mass. Comp. Asssoc. 

David Loveman, Mass. Comp. Assoc., Walker Royce, TRW 
SS-2: UNIX 

Co-Chairs: Prof. Domenico Ferrari, U. of California at Berkeley; Dr. 

Luis Felipe Cabrera, IBM San Jose Research Lab. 

Session 1: “UNIX: The Wave of The Past?” (Rm. 8-C) 

Session Chair: Dr. L.F. Cabrera, IBM Research 

William N. Joy, Sun Microsystems; Richard Rashid, Carnegie Mellon U.; 
Doug Mcllroy, AT&T Bell Laboratories; Keith Lantz, Stanford U. 

SS-3: Program Testing 

Chair: Prof. William Howden, U. of California at San Diego 
Session 1: “Current Problems in Program Testing” (Rm. 7-A) 

Session Chair: Prof. Lori Clarke, V. of Massachusetts at Amherst 
Richard Taylor, U. of California at Irvine 
SS-4: Programming Languages, Compilers and Environments 
Chair: Dr. John R. White, Xerox—Palo Alto Research Center 
Session 1: “Software Development Environment Issues” (Rm. 4-H) 
Session Chair: Dr. Barry Boehm, TRW 

S. Squires, DARPA; S. Redwine, Inst, of Def. Anal.; V. Basili, U. of 
Maryland; M. Penedo, TRW 

Session 2: “Integrated Programming Environments" (Rm. 5-B) 

Session Chair: Dr. Chandra M. R. Kintala, AT&T Bell Laboratories 
L. Druffel, Rational Inc.; W. Scacchi, USC; S. Reiss, Brown U. 

Session 3: “Issues in Code Generation” (Rm. 6-B) 

Session Chair: Dr. Peter Kessler, Xerox—Palo Alto Research Center 
Robert Henry, U. of Washington; Christopher Fraser, U. of Arizona; 
Michael Powell, Digital Equipment Corporation 
Session 4: “Programming Languages” (Rm. 7-B) 

Session Chair: Dr. John R. White, Xerox—Palo Alto Research Center 
A. W. Bojanczyk and T. D. Kimura, Washington U.; N. Cunniff, R.P. 
Taylor and M. Uchiyama, Columbia U.; C. C. Genet, Grumman Corp. 
Session 5: “Hypertext” (Rm. 1-B) 

Session Chair: Prof. Andries van Dam, Brown U. 

Norman Meyrowitz, Brown U.; Dr. Frank Halase, Xerox Parc; Dr. 

Mayer Schwartz, Tektronix, Inc. 


Computing Issues (LAC and STAN) 

LAC-l Legal and Professional Concerns 
Chair: Arthur Parry, The Wyatt Company 
Session I: “Legal/Professional” (Rm. 1-C) 

Session Chair: Dr. Alex Hoffman, Consultant 
Topics: Contracts, Copyrights, Professionalism 
STAN-1: Standards 

Chair: Laurel Kaleda, IBM Corporation 

Session 1: “Standardization—Where Should It Be By 2000?” (Rm. 4-C) 
Session Chair: Laurel Kaleda, IBM Corporation 
J. De Balsi, IBM; S. Sherr, IEC/ISO; J. Burroughs, NBS; H. Wood, 
IEEE, and F. Buckley, RCA. 


Algorithms (AL) 

AL-l: Artificial Intelligence Algorithms 
Chair: Prof. T. A. Marsland, U. of Alberta 
Session 1: “Computer Chess Techniques” (Rm. 3-H) 

Session Chair: Prof. T. A. Marsland, U. of Alberta 
T. A. Marsland, N. Srimani, and J. Schaeffer, U. of Alberta; Hans 
Berliner, Carnegie Mellon U.; Ken Thompson, AT&T Bell Laboratories; 
Monroe Newborn, McGill U.; Dave Levy, Chess Master, London; Robert 
Hyatt, U. of So. Miss. 

AL-2: Numerical Methods 

Chair: Dr. David R. Kincaid, U. of Texas at Austin 
Session 1: “Vector and Parallel Algorithms” (Rm. 7-D) 

Session Chair: Dr. David Kincaid, U. of Texas at Austin 
Eugene L. Wachspress, U. of Tennessee; Graham F. Carey, U. of Texas at 
Austin; John R. Rice, Purdue U.; O. G. Johnson, U. of Houston 
Session 2: “Finite Element Methods—A Tutorial” (Rm. 8-D) 

Session Chair: Linda J. Hayes, V. of Texas at Austin 

David M. Young, J. Tinsley Oden, and Steven R. Kennon, U. of Texas at 

Austin; George S. Dulikravich, Pennsylvania State U. 

AL-3: General Algorithms 

Chair: Prof. Paul Purdom, Indiana U. 

Session 1: “Searching” (Rm. 1-E) 

Session Chair: Prof. Cynthia Brown, Northeastern U. 

L. Finkelstein, Northeastern U.; D. Carlson, U. of Massachusetts at 
Amherst; R. Archuleta and H. D. Shapiro, U. of New Mexico 
Session 2: “Data Structures” (Rm. 2-E) 

Session Chair: Prof. Michael Loui, U. of Illinois 

I. Munro and O. Celis, Waterloo U.; F. B. Bastani, et al., U. of Houston; 
B. Abramson and M. M. Young, UCLA 

Session 3: “Optimization” (Rm. 3-E) 

Session Chair: Prof. Larry Ruzzo, U. of Washington 

J. Biswas and D. Matula, U. of Texas at Austin; T.J. Marlowe, Seton 
Hall U.; D. Armbruster, Institut fur Informatik—Stuttgart 


Modeling & Measurement (MM) 

MM-l: Performance Modeling and Measurement 

Chair: Dr. Stephen Lavenberg, IBM Thomas J. Watson Research Ctr. 

Session 1: “Performance Modeling Methods” (Rm. 2-G) 

Session Chair: Dr. Stephen Lavenberg, IBM T. J. Watson Research Ctr. 
K. C. Sevick, U. of Toronto, CSRI; E. Gelenbe, et al., U. of Paris Sud; I. 

K. Ryu and A. Thomasian, Burroughs Corp. 

Session 2: “Performance Studies” (Rm. 1-G) 

Session Chair: Dr. Stephen Lavenberg, IBM T. J. Watson Rsch. Ctr. 
M.S. Lakshmi, O.R. LaMaire, W.W. White, P.S. Yu, S. Balsamo, and Y. 
H. Lee, IBM T. J. Watson Research Center; D. Ferrari and S. Zhou, UC 
Berkeley 

Session 3: “Performance Modeling Workstations” (Rm. 3-B) 

Session Chair: Dr. Stephen Lavenberg, IBM T. J. Watson Research Ctr. 

J. B. Sinclair and S. Madala, Rice U.; J. F. Kurose, et al., U. of 

Massachusetts; B. Melamed, AT&T Bell Laboratories 

MM-2: The State of The Art of Capacity Management in MVS Systems 

Chair: Mr. Kenneth Kolence, Kolence Associates 

Session 1: “Capacity Managment l”(Rm. 3-G) 

Session Chair: Kenneth Kolence, Kolence Associates 

Dr. J.P. Buzen, BGS Systems; Dr. Brian J. Smith, IBM GPD 

Session 2: “Capacity Management 2” (Rm. 4-G) 

Session Chair: Kenneth Kolence, Kolence Associates 
Phillip C. Howard, Applied Computer Research; Dr. Tachen Lo, 
McDonnell Douglas; Dr. C.U. Smith, L&S Computer Technology. 
Session 3: “The Insularity of Performance Evaluation” Rm. S-G) 

Session Chair: Prof. Domenico Ferrari, U. of California at Berkeley 
Kenneth Kolence, Kolence Associates; Dr. Brian J. Smith, IBM San Jose; 
Mario Marino, Marino Associates; Dr. James C. Browne, U.T. at Austin 
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Computer Design (CD) 

I CD-I: Fault-tolerant Computing 
Chair: Prof. John Meyer, U. of Michigan 
Session 1: “Commercial Applications” (Rm. 4-E) 

Session Chair: Dr. Wing N. Toy, AT&T Bell Laboratories 
W. N. Toy and G. F. Clement, Bell Labs.; J. P. Kelly, Ford; J. Machulda, 
Triconix; D. E. Morgan, Motorola; J. H. Wensley, August Systems 
Session 2: “Evaluation” (Rm. 5-E) 

Session Chair: Prof. Kishor S. Trivedi, Duke U. 

B.R. Iyer, IBM T.J. Watson Research Center; R.K. Iyer, V. Sridhar, R. 
Sahner and K.S. Trivedi, U. of Illinois at Urbana; W.H. Sanders and J. F. 
» Meyer, U. of Michigan 
Session 3: “Testing” (Rm. 6-E) 

Session Chair: Prof. Edward J. McCluskey, Stanford U. 

' K.A. Hua and J.A. Abraham, U. of Illinois; S. Mourad et al, Stanford U.; 
: T. Kirkland and M. Mercer, U. of Texas at Austin 
i CD-2: VLSI Design and Test: Theory and Practice 
Chair: Mr. Jerome M. Kurtzberg, IBM T.J. Watson Research Center 
Session 1: “VLSI Techniques of Design Automation” (Rm. 1-F) 

Session Chair: Prof. Sheldon Akers, U. of Massachusetts at Amherst 
T.A. Onitiri and H.A. Hershey, AT&T Bell Laboratories; M. E. Breuer 
and X. Zhu, U. of Southern California; G.C. Gopalakrishnan, SUNY 
Session 2: “Expert Systems for Design and Test” (Rm. 7-1) 

Session Chair: Dr. Pradip Bose, IBM T.J. Watson Research Center 

J. A. B. Fortes and M. A. Samad, Purdue U.; G. Cabodi, P. Camurati 
and P. Prinetto, Politecnico di Torino; E. Dupont, et al.. Lab. Circiuts et 
: Systems, Grenoble; P.W. Horstmann, IBM Corporation 
Session 3: “Design Languages” (Rm. 8-B) 

Session Co-Chairpersons: Prof. Pei Hsia, U. of Texas at Arlington and 
Anthony Gargaro, CSC 

Dr. Gerald Fisher, IBM Research; Prof. Joe Urban, U. of Southwestern 
Louisiana; Dr. D. Luckham, Stanford U.; Prof. Kai Hwang, U. of 
i California 

Session 4: “VLSI Research in Universities” (Rm. 2-F) 

Session Chair: Prof. Timothy N. Trick, U. of Illinois at Urbana 
Prof. R. Zippel, MIT; Prof. J. Shen, Carnegie-Mellon U.; Prof. J. A. 
Abraham, U. of Illinois at Urbana; Prof. Carlo Sequin, U.C. at Berkeley 
Session 5: “VLSI Fault Tolerant Goals” (Rm. 3-F) 

I Session Chair: Prof. Dhiraj K. Pradhan, U. of Massachusetts at Amherst 
1 Prof. Edward J. McCluskey, Stanford U.; Dr. Allen Anderson, MIT; Dr. 

' Jeffrey Fried, GTE Laboratories; Dr. Israel Koren, Technion Institute of 
; Technology; Dr. Hideo Kikuchi, NIT; Dr. Gabriele Saucier, LCS 
| CD-3: Computer Graphics 

Chair: Prof. Michael Wozny, Rensselaer Polytechnic Institute 
Session I: “Computer Graphics Standards” (Rm. 9-E) 

Session Chair: Prof. Michael J. Wozny, Rensselaer Polytechnic Institute 
! Dr. David Vanderschel and Chris Nelson, Nova Graphics International; 
Salim Abi-Ezzi, Rensselaer Polytechnic Institute 
Session 2: “Computer Geometry” (Rm. 7-E) 

Session Chair: Dr. Louis Doctor, Raster Technologies, Inc. 

L. Leff and D. Yun, S.M.U.; D. Breen and P. Getto, Rensselaer Poly. Inst. 


Education (ED) 

| ED-1: New Technology in Education 

Chair: Dr. Lionel V. Baldwin, President, National Technological U. 
Session 1: “Technical Education By Satellite” (Rm. 2-B) 

Session Chair: Dr. Lionel V. Baldwin, NTU 

John T. Fitch, Associate Director, Association for Media-Based 

Continuing Education for Engineers (AMCEE); Prof. Frederic J. Mowle, 

Purdue U.; Prof. Sartaj Sahni, U. of Minnesota 

Session 2: “Computers in Education” (Rm. 4-B) 

Session Chair: Arthur S. Melmed, Consultant 

Dustin H. Heuston, Chairman, WICAT Systems, Inc.; Prof. Bruce A. 

Sherwood, Carnegie-Mellon U.; Prof. Alan Lesgold, U. of Pittsburgh 


Computer Developments in Japan (ID) 

ID-1: Computer Developments in Japan 
Chair: Prof. Ryoichi Mori, U. of Tsukuba 
Secretariat: Mr. Kenji Naemura, NTT Elec. Comm. Lab. 

Session 1: “Fifth Generation Computers I: Language Arch.”(Rm. 4-F) 

Session Chair: Dr. Koichi Furukawa, ICOT 

J. Tanaka, et al., ICOT; H. Masuzawa, et al., Fujitsu; T. Kurokawa, et al., 

IBM Japan; Y. Kiyoki, et al., U. of Tsukuba 

Session 2: “Fifth Generation Computers II: Applications" (Rm. 5-F) 

Session Chair: Dr. Koichi Furukawa, ICOT 

T. Mano, Fujitsu; H. Miyoshi, ICOT; H. Fujita, Mitsubishi Electric 

Session 3: “Advanced Microcomputer Developments” (Rm. 6-F) 

Session Chair: Prof. Iwao Morishita, U. of Tokyo 

H. Kaneko, et al„ NEC; T. Saito, Toshiba; H. Maejima, Hitachi 

Session 4: “Supercomputing Systems” (Rm. 7-F) 

Session Chair: Yoshikuni Okada, Electrotechnical Laboratory 

K. Miura, Fujitsu America; C. Kon’no, Hitachi; M. Tsukagoshi, NEC; T. 
Higuchi, ETL 

Session 5: “Interworking Systems” (Rm. 8-F) 

Session Chair: Kenji Naemura, NTT Electrical Communications Labs. 

M. Kurata, NTT; K. Mori, Hitachi, Ltd; M. Yoshida, Oki Electric 

Operating Systems & Data Bases 
(OSDB) 

OSDB-l: Operating Systems 

Chair: Dr. James Peterson, MCC 

Session 1: “Applications of Petri-Nets” (Rm. 7-H) 

Session Chair: Prof. Paul Reynolds, U. of Virginia 

B. Shenker, U. of Ill.; M. Molloy, U.T. at Austin; 1. Forman, Microelect. 

& Comp. Tech.; M. Holliday and M. Vernon, U. of Wise. 

Session 2: “Security and Protection in Computer Systems” (Rm. 8-H) 

Session Chair: Dr. James Peterson, MCC 

R. Turn, Cal. State U., Northridge; M. Bishop, Rsch. Inst, for Adv. 

Comp. Science, NASA Ames Rsch. Ctr.; J. Driscoll, U. of Cen. Florida 
OSDB-2: “Distributed Operating Systems” 

Chair: Dr. Jack Stankovic, Carnegie-Mellon U. 

Session 1: “Distributed Operating Systems” (Rm. 5-H) 

Session Chair: Dr. Jack Stankovic, Carnegie Mellon U. 

R. Rashid, Carnegie Mellon U.; Dr. Ahmed Ezzat, Bell Labs.; R. Koo and 

S. Toueg, Cornell U.; P. Chrysanthis, U. of Mass, at Amherst 
Session 2: “Distributed Databases” (Rm. 6-H) 

Session Chair: Prof Hector Garcia-Molina, Princeton U. 

W.H. Kohler and B.C. Jenq, U. of Massachusetts at Amherst; M. 

Rusinkiewicz and D. Georgakopoulos, U. of Houston; J. Kim and G. 

Belford, U. of Illinois Urbana-Champaign; J. Noe, U. of Washington 
OSDB-3: Data Bases 

Chair: Dr. Anil Nigam, IBM T.J. Watson Research Center 
Session 1: “Data Bases” (Rm. 1-H) 

Session Chair: Dr. Anil Nigam, IBM T.J. Watson Research Center 

L. L. Miller and A.R. Hurson, Pennsylvania State U.; G. Weikum, T U 
Darmstadt; M. Eich, Southern Methodist U.; M. Hirakawa, Hiroshima U. 

Education (ED) 

ED " 2: Software-Engineering Education 
Chair: Prof. Norman Gibbs, Carnegie-Mellon U. 

Session 1: “How Universities Educate Software Engineers” (Rm. 8-A) 

Session Chair: Prof. Richard Fairley, Wang Inst, of Grad. Studies 
James Comer, Texas Christian U.; Peter Freeman, UC at Irvine 

Session 2: “Software Engineering Education in Companies” (Rm. 9-A) 

Session Chair: Dr. S.E. Smith, IBM Corporate Technical Institutes 
Ilene Birkwood, HP; Dr. D. Clayton, AT&T Bell Labs. 
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To obtain additional Registration Forms or for further information, contact FJCC ’86, 1730 Massuchusetts Ave., 
N.W., Washington, D.C. 20036-1903; (800) 722-FJCC. 


Dallas 

Dallas is a music town, a theater town, a nightclubbing town, a 
conference town, a friendly town. 

Of the 45,000 businesses located in Dallas and the surrounding area, 
nearly 400 of these are headquarters or regional facilities for leading 
electronic and information processing companies. 

Dallas is the place to be November 2-6 for the Fall Joint Computer 
Conference, when thousands of professionals will be gathering at 
INFOMART to Explore the Knowledge-Based Society. 

INFOMART 

The world’s first market center for the information processing industry! 
Inspired by London’s Crystal Palace at the 1851 Great Exhibition, this 
soaring, glass vaulted building, provides under one roof, a fabulous high- 
tech setting for a fabulous, not-to-be-missed, high-tech event... FJCC 86. 

Transportation from Dallas/Ft. Worth Airport 

Complete information on transportation to the conference Hotels (all 
located within the Dallas Market Center area) is posted on a 
Transportation Information Board located at or near your arrival gate. 
Additional information concerning pick-up points at the airport is 
available in the baggage claim area. 

Most commercial bus, mini-bus, or van service costs are approximately 
$8-10 and take about 35 minutes. 

Taxi fare runs about $21 plus tip. Three or more persons sharing a cab 
can be as cost effective as the commercial bus service. 

Exhibits 

Educational and technical exhibits will complement the Conference 
technical program, highlighting the technological basis of the latest 
products, and services in the computing field. The exhibits will be open in 
the Infomart during the hours of 12 noon to 5 pm, Monday thru 
Thursday, November 3-6. 

For complete details on reserving booth space, contact David 
McKeever, INFOMART, (214) 746-3500. 

Exhibitor Technical Forums 

Key Vendors will provide chief scientists or other senior engineering 
personnel to discuss and explain the technology embedded in their 
principal product offerings. 


Program Highlights 
Keynote/Plenary Sessions 

Tuesday and Wednesday mornings, November 4 and 5, 8:30-9:30 am 
will be our opening Conference plenary sessions. There will be an 
Industrial Keynoter on Tuesday; and on Wednesday, Kenneth Wilson, 
Nobel Laureate of Cornell University and C. Gordon Bell, NSF will 
speak. 

Turing Award/Plenary Session 

Thursday morning, 8:30-9:30, will be the session during which the 
ACM’s most prestigious citation, the Turing Award, will be announced. 
The Turing Award Lecture is always an outstanding technical presentation 
of interest to a wide variety of people. 

Conference Registration 

All persons attending the conference are required to register and pay the 
appropriate fee. You may register in advance and save the on-site fee, by 
using the form in this program. A check or money order, in U.S. currency, 
payable to FJCC ’86 must be included with this form, or the proper credit 
card authorization must be filled out. Refund requests must be received in 
writing by October 17, 1986. 

On-Site Registration will take place during the following hours at both the 
Infomart in the main lobby and at the Anatole Hotel on the mezzanine; 
pre-registrants who did not receive their registration packets may pickup 
these materials at the Infomart: 

Saturday & Sunday, November 1 & 2 - 12 noon to 5 PM 

Monday, 7:30 AM to 10 PM 

Tuesday-Thursday, November 2 thru 6-9 AM to 5 PM 
Conference Location 

All conference activities will be held at either the INFOMART, Dallas, 
Texas, or Loew’s Anatole Hotel, 2201 Stemmons Freeway, Dallas, TX 
15201, 214-748-1200. Activities scheduled for the Anatole include the daily 
Keynote/Plenaries, 8:30-9:30 Tuesday thru Thursday; the Technical 
Program, 9:30-5:15 Tuesday thru Thursday; Poster Sessions (for last 
minute submitted papers), 9:30-5:15 Tuesday thru Thursday; and the 
North American Chess Championship Tournament. 

INFOMART will be the site of the exhibits, 12 noon-5 pm, Monday 
thru Thursday, the Exhibitor Technical Forums, the Professional 
Education Program Courses (PEP) 9:30-5:30 Sunday and 8:30-4:30 
Monday; and the World Micro-Chess Championship matches. 


What to Wear 

You can expect the temperatures in Dallas, in November, to be in the 
60’s or low 70’s. Although the skies in November are generally clear, 
precipitation could be expected in the evening or at night. 

Travel Services 

Wyndham Travel has been appointed FJCC travel coordinator. For 
special air fares or a specially reduced rate of $29 per day on rental cars 
from National, (unlimited mileage) call the FJCC Travel Desk at 
1-800-972-1163. From Canada call collect 214-655-6248. 

A 50% discount on FJCC shuttle transportation from Dallas/Fort 
Worth and Love field airports to your hotel is available when you 
purchase your airline ticket thru the FJCC Travel Desk. 

Tax Deductibility 

Expenses of attending professional meetings, such as registration fees 
and costs of technical publications, have been held to be tax deductible as 
ordinary and necessary business expenses for U.S. citizens. 

Proceedings 

Proceedings are included in the full Conference & Exhibits registration, 
and will be available at the Conference. 


Both the Anatole and INFOMART will house an FJCC 116 Conference 
Information Center. 


EXHIBITORS 

A partial list of some 150 planned exhibitors as of July 15, 1986 


Allyn & Bacon, Inc. 
Arthur Andersen 
A.D. Little, Inc. 

Arthur Young 
Autocad, Autodesk, Inc. 
AVCO Electronics 
Benjamin/ Cummings 
Boeing Computer Services 


Cadre Technologies 

Canstar Communications Div. 

Career Research Systems, Inc. 

Dallas Digital 

DataTimes 

Epson America, Inc. 

Expert Systems Inti. 

Gartner Group 


Gold Hill Computers 
Grid Systems 
IBM 

IMSL, Inc. 

Inference 

LISP 

Lee Data Corp. 

Liebert Corporation 
Microsoft 

Mitek Systems Corporation 

NCR 

Novell 

Printronix, Inc. 

RCA American Communications, Inc. 
Symbolics, Inc. 

Texas Instruments 
Westinghouse Electronics 
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FJCC *86 CONFERENCE REGISTRATION FORM 


95201; Phone; 1-800-722-FJCC 

or the Conference or the Professional Education Program and who have not received their conference credentials by 
ginning on Saturday, November 1 at 12 Noon until 5 PM at Infomart/main lobby counter. Please bring your registratic 
n line. Notices of cancellation must be received in writing at the FJCC Registration office NO LATER than October 17, 


MAIL LIST RESTRICTIONS: □ NO RESTRICTION □ PROFESSIONAL SOCIETY USE ONLY 



R IEEE-CS MEMBER NUMBER: _ 
JOB FUNCTION 


INDUSTRY 


□ Management 01 

□ Project Leader 02 

□ Systems Analyst 03 

□ Software Engineer 04 

□ Programmer 05 

□ Data Base Manager 06 

□ Mtg. Comm. Eng. 07 

□ Univ./Coll. Eng. 08 

□ Pri./Sec. Educator 09 

□ Research 10 

□ Administrator 11 

□ Consultant 12 

□ Other_13 


□ Banking/Fin. 14 

□ Comp. Svcs. Reseller 15 

□ Consulting 16 

□ DP Services 17 

□ Education 18 

□ Engr./Arch. Svcs. 19 

□ Gov’t 20 

□ Info. Sys. Mfg. 21 

□ Med/Health Care 22 

□ Petrochem. 23 

□ Retail 24 

□ Transportation 25 

□ Other_26 


Professional 

Education 

Program Course 

One-Day Courses 

Two-Day Courses 

Advance 

Registration 
(Before Oct. 18, 1986) 

Regular/ 

On-Site 

Registration 

Advance 

Registration 
(Before Oct. 18, 1986) 

Regular/ 

On-Site 

Registration 

“ember 

$200 

$250 

$240 

$300 

$450 

$550 

$550 

Course Number(s) 

Sunday J-Q-J Monday Q-J-J 

Sunday and Monday 


er made payable in US funds to FJCC '86, foi 


FJCC ^6 HOTEL RESERVATION FORM 

Mail this form to: FJCC Housing Bureau, Dallas Convention Bureau, 1507 Pacific Avenue, Dallas, TX 75201 - Telephone 
Hotels must be made through the FJCC Housing Bureau. Room requests must be received by October 3, 1986. 

To receive special “Conference Rates," our staff must make a reservation for you at the hotels listed below. Please indie 
3, and 4. IMPORTANT: Phone requests will NOT be honored. 

FJCC Housing Bureau wiU acknowledge receipt of your hotel reservation request. Confirmation of your hotel reservation wi 

not guarantee availability^ your Vo'om beyond ^OoV M ^nleTs rone^ight^deposk ‘has^eli «nt° Vtlwhotel . 1 ^ NOT' 
BUREAU. 


D DEPOSIT TO THE FJCC HOUSING 


Choice 

Hotel 

□ Single 

□ Double 

□ Triple 

□ Suite 


Loews Anatole 

$90 

$104 

$120 

Available Upon Request 


Marriott Market Center 

$75 

$ 85 

$ 85 

Available Upon Request 


Wyndham* 

$85 

$100 

$115 

N/A 


Viscount 

$48 

$ 52 

$ 58 

N / A 


STREET ADDRESS 


BUSINESS PHONE 


Check-out Date/ 





























































CALL FOR PAPERS 



The Seventeenth International 
Symposium on Fault-Tolerant 
Computing 

JUNE 17 - 19, 1987 
PORTLAND, OREGON, USA 


tc chairman Sponsored by: IEEE Computer Society’s Technical 

t. Anderson Committee on Fault-Tolerant Computing 

Univ. of Newcastle, England 


Symposium Chairman 

J. Wensley 

August Sys., Ptld., OR, USA 

Program Co-Chairmen 

J. Goldberg 

SRI, Menlo Park, CA, USA 

F. Christian 

IBM, San Jose, CA, USA 

Publicity Chairman 

B. Bose 

Oregon St. Univ., OR, USA 

Program Committee Members 

J. Abraham, USA 

V. Agraval, Canada 
S. Akers, USA 

P. Bernstein, USA 
J. Gray, USA 

J. Hayes, USA 
H. Ihara, Japan 
R. Iyer, USA 

K. Kinoshita, Japan 
J. Knight, USA 

H. Kopetz, Austria 

L. Lamport, USA 

J. Laprie, France 

G. Le Lann, France 
N. Leveson, USA 
B. Liskov, USA 

B. Littlewood, UK 

E. McCluskey, USA 

M. Melliar-Smith, USA 
D. Parnas, Canada 

D. Rennels, USA 
R. Shlichting, USA 

F. Schneider, USA 
D. Siewiorek, USA 
D. Skeen, USA 

B. Smith, USA 
Y. Tohma, Japan 

W. Toy, USA 

K. Trivedi, USA 


The Fault-Tolerant Computing Sympo¬ 
sium has, since 1971, become the most 
important forum for discussion of the 
state-of-the-art in fault-tolerant 
computing. In 1987 the symposium will 
be held in Portland, Oregon, USA. Mr. 
John Wensley, August Systems, Inc., 
18277 S.W. Boones Ferry Road, Tigard, 
Oregon, 97224, tel. (503) 684-3550 is the 
Symposium Chairman. 


FTCS17 will address all aspects of 
specifying, designing, testing, 
diagnosing and evaluating dependable 
and fault tolerant computing systems 
and their components, particular 
emphasis will be placed on papers 
relating to practical experience with real 
time systems, switching systems and 
transaction systems as well as the 
application of fault-tolerance to the 
design of safety critical systems. 

Information for the Authors: Authors 
should submit 6 copies of papers before 
the submission deadline November 21, 
1965, to the Program Co-Chairman; Dr. 
Flaviu Cristian, IBM Research K55/801,650 
Harry road, San Jose, CA 95120-6099, USA, 
and Mr. Jack Goldberg, SRI Int’l, 333 
Ravenswood Ave., Menlo Pk., CA 94025. 
papers in areas a, b, and f, should be sent 
to Dr. Cristian, and papers in areas c, d, and 
e, to Mr. Goldberg. 


Papers should be no longer than 5,000 
words, should includeaclear description 
of the problem being discussed, 
comparisons with extant work, and a 
section on major original contributions. 
The front page should include a contact 
author’s complete mailing address, 
telephone number and net address (if 
available), and should clearly indicate the 
paper’s word count and the area to which 
the paper is submitted. Submissions 
arriving late or departing significantly 
from these guidelines risk rejections 
without consideration of their merits. 

Papers relating to the following areas are 
invited: 

a) Design methods and basic algorithms 
for distributed fault-tolerant systems 

b) Specification, design, testing, verifica¬ 
tion of reliable software, 

c) Specification, design, testing, verifica¬ 
tion, and diagnosis of reliable 
hardware 

d) Fault-tolerant hardware systems 
architectures 

e) Reliability, availability, safety 
modeling and measurements, 

f) Fault-tolerant computing systems for 
safe process control, digital 
switching, manufacturing automation, 
and on-line transaction processing. 


H IEEE COMPUTER SOCIETY 


Important Date 

November 25, 1986 . 

Submission Deadline THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, INC. 









IEEE Computer Society Election 


Nominees for Computer Society Office 
and Board of Governors 


On this and on the following pages are the position statements and biographies 
of the Computer Society’s candidates for president, president-elect, first and sec¬ 
ond vice presidents, and Board of Governors. Within each category, candidates are 
listed in alphabetical order. 

Election of officers to one-year terms and board members to two-year terms, 
each beginning January 1, 1987, will be by vote of the membership as specified in 
the bylaws. Ballots, which will be mailed to all society members about September 8, 
must be received at IEEE Headquarters by October 20, 1986. Election results will 
be announced in the December issue of Computer. 

The opinions expressed in the following statements are those of the individual 
candidates and do not necessarily reflect society positions or policies. 


Constitutional Amendments 

The Board of Governors of the IEEE Computer Society unanimously recommends 
a vote for the following two constitutional amendments. Approval requires for votes 
by two-thirds of the members voting. 


Past President 

At its May 9, 1986 meeting, the Board of Governors of the Computer Society approved a 
change in the constitutional reference to the most recent past president, who serves on the 
Board of Governors and Executive Committee, from “junior past president” to “immediate 
past president.” The intent is to clarify the reference and to bring it into conformance with the 
practice of other associations, allowing the simple title of past president. 

Article III, Section 1 


Current wording. The Society shall be 
governed by the Board. All members of the 
Board must be members of the Society. The 
franchised members of the Board shall be the 
Society president, president-elect, first and 
second vice presidents, the [junior] past presi¬ 
dent, and twenty elected members of the 
Board. Ex officio members of the Board may 
be designated in the bylaws. The ex officio 
members of the Board shall have no vote 
unless they hold one as a franchised member 
of the Board. 


Proposed wording. The Society shall be 
governed by the Board. All members of the 
Board must be members of the Society. The 
franchised members of the Board shall be the 
Society president, president-elect, first and 
second vice presidents, the <immediate?- 
past president, and twenty elected members of 
the Board. Ex officio members of the Board 
may be designated in the bylaws. The ex of¬ 
ficio members of the Board shall have no vote 
unless they hold one as a franchised member 
of the Board. 


Majority Vote 

On March 7, 1986, the Board of Governors approved a change in Article III, Section 6 of the 
Constitution, which deals with the voting requirement for passage of motions. The change 
replaces “a majority vote of the franchised Board members present” to simply “a majority 
vote.” The purpose of the proposed change is to prevent an abstention from acting as a 
negative vote, and to simplify the voting process so that it will conform with the recommenda¬ 
tions of Robert’s Rules of Order and the practice of most organizations. 

Article III, Section 6 


Current wording. The presence of a majori¬ 
ty of the franchised Board members shall con¬ 
stitute a quorum. Proxies shall not be used to 
constitute a quorum. When a quorum is pres¬ 
ent at a meeting, a majority vote [of the fran¬ 
chised Board members present] shall be 
necessary for the conduct of business except 
as otherwise provided in the Society’s con¬ 
stitution and bylaws. The presiding officer 
may vote only when a secret ballot is called 
for or to resolve ties. 


Proposed wording. The presence of a ma¬ 
jority of the franchised Board members shall 
constitute a quorum. Proxies shall not be 
used to constitute a quorum. When a quorum 
is present at a meeting, a majority vote shall 
be necessary for the conduct of business ex¬ 
cept as otherwise provided in the Society’s 
constitution and bylaws. The presiding officer 
may vote only when a secret ballot is called 
for or to resolve ties. 


Nominee for President 



Roy L. Russo 

Position statement. I 
would like to state what 
has been accomplished 
during my first six 
months as president, as 
well as state future 
goals. 

One of the major 
problems that has been 

_ __ addressed is keeping the 

1986 deficit under control. As income 
dropped from various sources because of the 
slump in the computer industry, cuts were in¬ 
stituted totaling almost S600K and affecting 
all society operations. This followed hundreds 
of thousands of dollars in savings measures to 
produce our magazines. These moves were 
met with a high level of cooperation from 
both volunteers and staff. One of the steps 
that the Board found necessary to take was to 
increase the 1987 member fee by $5 to $15; 
this should enable the 1987 budget to show a 
surplus and help provide funds for initiating 
new activities in future years. 

Another major problem that has been ad¬ 
dressed is high staff turnover. We have im¬ 
plemented a compensation program recom¬ 
mended by a management consulting firm, 
balanced staff workload against resources, 
and established a human resources committee 
to recommend personnel policies and pro¬ 
cedures. In addition, we have emphasized 
teamwork and management techniques at the 
senior manager level. 

We have taken steps to become a more in¬ 
ternational society. We have established a 
European Advisory Committee to assist in the 
operation of our office in Brussels and to ad¬ 
vise the society leadership on all areas of in¬ 
terest to our European members. We have ini¬ 
tiated an affiliate member relationship with 
the Information Processing Society of Japan. 

We have taken a leadership role in AFIPS 
(American Federation of Information Pro¬ 
cessing Societies) by developing a proposal to 
restructure AFIPS so as to enable the AFIPS 
Board to concentrate on policy issues. 

My key goals are 

(1) to reorganize the society to enable us to 
meet future member requirements, 

(2) to maintain a sound financial position, 

(3) to work closely with the first president¬ 
elect to establish the office as a key ele¬ 
ment in the society structure, 

(4) to initiate self-assessment of all 
volunteer operations to assure high 
quality in member services, and 

(5) to continue to work to strengthen 
AFIPS. 

Despite the current problems in the com¬ 
puter industry, your society continues to be 
strong in its membership, its volunteers and 
staff, and its financial reserves. I will work to 
keep the society strong, and I welcome your 
support and ideas. 


Biography. Currently president, Russo has 
served the society in various leadership posi¬ 
tions for over 10 years. He founded IEEE 
Design & Test of Computers magazine and 
served as its first editor-in-chief (1983-85). 
During his term as vice president for con¬ 
ferences and tutorials (1985), he developed the 
society’s first conference handbook that 
codified all conference policies. As vice presi¬ 
dent for technical activities (1982-83), he in- 
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itiated the Robotics, Personal Computing, 
Computer Languages, and Computers in 
Education technical committees, and in¬ 
troduced the concept of a vice president for 
standards (now adopted). As treasurer (1981), 
he developed a uniform accounting system 
with the IEEE and initiated the Computer 
Services Advisory Committee. He has served 
as Executive Committee member (1981-86), 
Governing Board member (1979-1986), 

AFIPS director (1986), chairperson of the 
Design Automation Technical Committee 
(1976-77), and as a member of numerous 
other committees and boards. 

An IEEE Fellow, he is a member of ACM, 
Eta Kappa Nu, and Sigma Xi. Russo is 
manager of the Advanced Design Automation 
Laboratory at the IBM T.J. Watson Research 
Center. Previously, he was a senior engineer 
and research staff member at IBM, a con¬ 
sulting professor at Stanford, and an assistant 
professor an Penn State. 

Russo earned the PhD degree (EE) from 
Pennsylvania State University. He received the 
IEEE Centennial Medal, the Distinguished 
Service Award from the Computer Society, 
the L. A. Dogget Award for outstanding 
writing in electrical engineering from Penn 
State, and an Outstanding Contribution 
Award and Invention Achievement Award 
from IBM. 


Nominees for President-Elect 


Taylor L. Booth 

Position statement. The 
Computer Society needs 
strong leadership in the 
next few years. I seek 
your vote for president¬ 
elect because I believe 
my experience in the 
publications, con¬ 
ference, and education 
areas and my service on 
the Governing Board provide the background 
necessary to supply this leadership. The socie¬ 
ty must offer the services, publications, and 
activities that serve the needs of our diverse 
membership. At the same time, all current 
and proposed new programs must be reviewed 
to make sure that their costs are in line with 
the benefits provided to the membership. 

Specifically, I propose the following 
initiatives: 

(1) Our publications must be responsive to 
the changes occurring in the computer field. 
The magazines must carry timely and read¬ 
able articles that provide the background 
needed to understand and apply new devel¬ 
opments. The transactions must seek out and 
publish new research-and-development results 
with minimal delay. 

(2) We must review the organization and 
management structure of the society to ensure 
that the society operates efficiently and is 
responsive to members’ needs and requests. 
This structure must include well-defined 
channels for communication between the 
volunteers and the professional staff so that 
all current or proposed programs are evalu¬ 
ated in terms of expected benefits. 

(3) We must be more aggressive in speaking 
for the profession. This can be accomplished 
by insuring that our members are called upon 
to represent the computer profession on na¬ 
tional and international boards and commis¬ 
sions as well as appearing before congres¬ 
sional committees to provide expert testimony 
on topics of importance to the computer 
field. 

(4) We must develop effective methods of 
providing such continuing education oppor¬ 



tunities for the membership as home study 
and chapter tutorials as well as tutorials at na¬ 
tional meetings. 

(5) We must continue to play an active role 
in helping to shape IEEE policies and pro¬ 
grams so as to reduce overlapping member 
services and programs. 

(6) We must continue working with the 
ACM to increase cooperation and reduce 
duplication of effort, particularly in the areas 
of conferences, tutorials, publications, and 
education. 

Working together, we can ensure the con¬ 
tinued growth and strength of the Computer 
Society. 

Biography. Booth has served the Computer 
Society as first vice president, secretary, vice 
president for educational activities, and Gov¬ 
erning Board member. He has been editor-in- 
chief of IEEE Transactions on Computers, a 
Distinguished Visitor, and a founding member 
and the first president of the Computing 
Sciences Accreditation Board. He has served 
on the program committees of a number of 
IEEE-CS conferences, and is presently 
chairperson of the Constitution and Bylaws 
Committee and a member of the Publications 
Board and the Educational Activities Board. 

An IEEE Fellow, Booth is an IEEE 
representative to the Engineering Accredita¬ 
tion Commission and an alternate member of 
the Accreditation Board for Engineering and 
Technology. He was a member of the IEEE 
EAB. 

Booth is director of the Computer Applica¬ 
tions and Research Center and professor of 
Computer Science and Engineering at the 
University of Connecticut. His research in¬ 
terests include software engineering and the 
design of high-performance software. He is 
the author or coauthor of three books and 
numerous papers. Formerly an engineer with 
Westinghouse, he now consults for DEC and 
several Connecticut companies. 

He received his BS, MS and PhD in elec¬ 
trical engineering from the University of Con¬ 
necticut. Booth received the Frederic Emmons 
Terman Award in 1972 and the IEEE Centen¬ 
nial Medal in 1984. He is listed in Who's Who 
in America and other similar publications. 


Edward Parrish 

Position statement. The 
Computer Society has 
recently experienced 
unprecedented growth, 
not only in membership 
but also in technical 
scope and expanding ac¬ 
tivities. This growth has 
had obvious positive 
benefits for the member 
ship, most visibly through excellent publica¬ 
tions. The downside of the expanding ac¬ 
tivities is manifested in almost uncontrollable 
expenses exacerbated by the downturn in the 
electronics industry. Like other related 
businesses, the Computer Society is now ex¬ 
periencing financial difficulties and must take 
appropriate steps to recover. 

This became very evident during my service 
this year on the NCC and the AFIPS con¬ 
ference boards. In the past, the NCC was a 
budgetary mainstay for the society, yielding a 
large surplus each year that surpassed finan¬ 
cial planning assumptions and masked errors. 
This year there are no distributions from 
AFIPS, and the member societies are suffer¬ 
ing because of it. The Computer Society will 
not be run successfully if it is managed as in 
the past, when numerous volunteers indepen¬ 
dently estimated projections, which then col¬ 
lectively formed the annual budget. Rather, it 
must be run as a business—with sound finan¬ 



cial planning and a strategic plan that encom¬ 
passes its chosen activities. 

For example, conferences must be given 
closer scrutiny to ensure the recovery and 
revitalization of this very important activity. 
Where possible, joint ventures with ACM and 
other national/international organizations 
should be undertaken to reduce the expenses 
for each and to eliminate redundant and com¬ 
peting activities. 

It is my contention that the current situa¬ 
tion can be reversed through thoughtful plan¬ 
ning and sound management without sacrific¬ 
ing the quality of either publications or major 
conferences. The Computer Society should 
not react by raising taxes (subscription and 
conference rates), but rather by reducing the 
expense side of the ledger. To this end, I 
would attempt to streamline operations at the 
staff level while reducing or eliminating those 
activities that provide little benefit to the ma¬ 
jority of the membership but are very costly 
to carry out. In addition, I would appoint ex¬ 
perienced managers from industry to the 
Executive Committee so the society would 
benefit from their business acumen. Such 
actions would reduce the society’s exposure to 
difficulty and restore vitality to the largest 
entity within the IEEE. 

Biography. Parrish, a Fellow of the IEEE, is 
presently a member of the Computer 
magazine Editorial Board, the Advisory 
Board of PAMI, the Educational Activities 
Board, and the IEEE TAB Search 
Committee. 

He has also served on the IEEE Transna¬ 
tional Relations and Membership Develop¬ 
ment committees, as well as the NCC and 
AFIPs conference boards. He was vice presi¬ 
dent for technical activities, 1981; for the 
Software and Applications Technical Interest 
Council, 1980; first vice president, 1979; sec¬ 
ond vice president, 1978; and secretary, 1977. 
He served on the Board of Governors during 
1980-81 and 1975-77, and was a member of 
the Executive Committee from 1977-81. He 
was chairperson of the Conferences and 
Meetings Committee in 1976 and chairperson 
of the Membership Committee from 1975-76; 
Standards Committee member, 1972-75; 
Education Committee member, 1971-74; and 
member since 1970 and chairperson, 1978-84, 
of the Pattern Analysis and Machine In¬ 
telligence Technical Committee. He has also 
served on program committees of several 
conferences, most recently as program 
cochairperson of the First International Con¬ 
ference on Computers and Applications, June 
20-22, 1984, Beijing, PRC. 

Parrish currently chairs the Dept, of Elec¬ 
trical Engineering, University of Virginia. He 
received the BEE, MEE, and ScD in electrical 
engineering from the University of Virginia. 


Nominees for 
First Vice President 


James Aylor 

Position statement. 
Because of the current 
slump in the computer 
and electronics industry, 
the Computer Society 
faces a new and general¬ 
ly unfamiliar challenge: 
to continue to provide 
high-quality professional 
services to its constituen¬ 
cy in light of extreme financial strain. As the 
current vice president for conferences and 
tutorials, I have attempted, with the help of 
many dedicated volunteers, to balance the 
support of new and innovative ideas with the 
financial needs of the society. 
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The close examination of programs and 
services as to their benefit to the membership 
must be continued in 1987. Past success of the 
society can be largely attributed to the flex¬ 
ibility to quickly implement new and in¬ 
novative ideas. New programs and additional 
services to the members can only be afforded 
by establishing and maintaining financially 
strong conferences and publications. Such 
success is only possible through careful and 
controlled operation and expansion of the lat- 

The Computer Society should encourage 
increased cooperation with ACM and with 
other societies within IEEE. We should more 
actively pursue the creation of jointly spon¬ 
sored activities with member societies of our 
parent organization. Broadening the scope of 
cooperation will reach a wider audience, mini¬ 
mize duplication, and combine resources. Co¬ 
operative efforts with European and Japanese 
national societies should be expanded to in¬ 
crease the international stature of the society. 

Most importantly, the society must support 
and recognize its volunteers, through whom 
its success has been possible. 

I solicit your support. 

Biography. Aylor, currently the vice presi¬ 
dent for conferences and tutorials, has been 
active in the Computer Society since 1975, 
when he served as the secretary of the 
Technical Interest Council, the predecessor 
of the Technical Activities Board Opcom. 
Since that time, he has served in numerous 
capacities within TAB, including founder 
and chairperson of the Technical Committee 
on Computing and the Handicapped. He 
was a member of the Governing Board from 
1983 through 1985 and has served as a 
member of the Audit, Computer Services 
Advisory, Computer Society Press Advisory, 
Computer Magazine Advisory, and Fall 
Joint Computer Conference Steering com¬ 
mittees. He is also currently a member of the 
IEEE Press Editorial Board. 

A Senior Member of IEEE, Aylor also 
belongs to Sigma Xi, Tau Beta Pi, AAAS, 
and the Rehabilitation Society of North 
America. 

Aylor is an associate professor of electrical 
engineering and director of the Center for 
Semicustom Integrated Systems at the Univer¬ 
sity of Virginia. He has worked for the 
Federal Systems Division of IBM, where he 
currently does consulting work. His research 
interests are in the areas of design automation 
of digital systems, VLSI systems, fault 
tolerance and test technology, and microcom¬ 
puter applications. 


Michael C. Mulder 

Position statement. Our 
society continues to 
evolve, mostly in ways 
that benefit us all. My 
major concern is that we 
are no longer a small so¬ 
ciety, and thus some of 
the old methods and 
policies don’t work as 
well any more. As tech¬ 
nology changes, we must adapt if we are to 
continue to provide high-quality technical 
leadership for our membership—working en¬ 
gineers, teachers, and researchers alike. 

We must find and nurture imaginative, 
strong, and experienced leadership; I hope to 
contribute these on your behalf. To be 
specific; 

• I will pursue growth in our technical 
publications, more industry participation in 
these publications, improvement in the quality 
of our publications by more extensive peer 
review—all while keeping costs to the 
membership low. 
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• I will pursue a policy of continuing co¬ 
operation with our sister societies and a 
policy of strong society contribution to com¬ 
puter science and engineering education. 
There is a huge shortage of qualified 
teachers that continues to worsen; profes¬ 
sional societies must take a leadership role in 
correcting this problem. 

• Additionally, as America’s overseas com¬ 
petitors have shown, industry and universities 
must find ways to work together effectively 
towards reasonable partnerships. I will pursue 
methods by which IEEE- CS can influence 
how this can be done. 

I hope that you will elect me to the post of 
first vice president so that I can continue to 
contribute my time and energies to important 
issues facing the Computer Society. 

Biography. Mulder is director of the Applied 
Research Center and professor of electrical 
and computer engineering at the University of 
Portland. 

He is cofounder of Servio Logic Corp., 
where he was VP of engineering and a 
member of the Board of Directors. He is 
president of his own consulting firm and is 
engaged in advanced product development 
with a number of industrial clients. 

Previously, he was manager of systems de¬ 
velopment at ESI, Inc., senior research engi¬ 
neer at BPA, and manager of advanced sys¬ 
tems processors at Sperry Univac. 

He is currently Computer magazine editor- 
in-chief, a CSAB director, an IEEE-CS Board 
of Governors member, a past VP, Education 
Committee chairperson, Conferences and 
Meetings chairperson, Audit Committee 
member. 

Mulder has led several national task forces, 
and has successfully worked for cooperative 
ventures with ACM. 

He was a county planning commissioner, 
and is a member of the OIT State Advisory 
Board. He has been governor-appointed to 
the Oregon Resource and Technology 
Development Corp. He is an NSF grantee and 
a review panelist in the AI/Expert 
Systems/CIM area, and a member of IFIP 
10.2 WG on Systems Engineering. 

Mulder received his PhD in EE from Mon¬ 
tana State University, MSNE from University 
of Washington, BSEE from Oregon State 
University. 

He is a Registered Professional Engineer 
and an IEEE Senior Member. 


Nominees for Second Vice 
President 


Kenneth R. Anderson 

Position statement. One 
Computer Society re¬ 
sponsibility is providing 
information on the cur¬ 
rent and future state of 
the art in computer tech¬ 
nology. We currently ful- 
j fill this role by sponsor- 
j ing workshops, con- 
I ferences, tutorials, news¬ 
letters, magazines, and transactions. We have 
started new magazines, including Expert and 
IEEE Design & Test of Computers. 

The leadership for our programs originates 
in the 33 technical committees, which form 
the nucleus of IEEE-CS programs. This 
leadership is severely constrained in serving 
membership needs. One reason is the lack of 
an increase in direct staff support to sustain 
current and future activities in the same way 
increased support is provided to conferences 
and publications. 

Technical programs must find ways to 
become the driving force for serving new in¬ 



terest groups. These groups include people 
with interest and occupations in manufactur¬ 
ing automation, decision support systems, 
and health care. 

We must continue to expand our member¬ 
ship opportunities to interested scientists and 
engineers outside the US. 

If I am elected, my goals will include 

• Acquiring adequate staff support to 
assist the volunteer leaders in (a) chang¬ 
ing the role of Technical Activities Board 
from passive to active and (b) planning 
and research that define the programs 
essential to the future of the society. 

• Establishing new sources of funding that 
are less dependent on the US computer 
industry’s economic cycle. This is essen¬ 
tial if new programs are to be successful 
in serving new interest groups. 

• Incentive programs to stimulate technical 
activities and projects and to encourage 
new initiatives. 

• Affiliation of our technical activities with 
those of emerging interest groups both 
within and external to the society. 

Biography. Anderson, a member of the 
Governing Board (1983-86), serves on the 
East Coast Operations, Audit, and Human 
Resource committees. He is a member of the 
Technical Activities Board Operation Com¬ 
mittee and the Conference and Tutorials 
Board, where he serves as vice chairperson 
and liaison for TAB. He is a member of the 
Test Technology Technical Committee, where 
he serves as chairperson of the tutorials sub¬ 
committee that was responsible for the suc¬ 
cessful International Test Conference pre¬ 
conference tutorial program. He is a member 
of the Design & Test Editorial Board. Other 
activities include the Committee on Public 
Policy and IEEE USAB PACE Division V 
representative. 

A group leader in the Siemens Corporate 
Research and Technology Division, Anderson 
started its research in microelectronic design 
and test. He is establishing research activities 
in factory-automated test and quality 
management. 

Before joining Siemens, he was an engi¬ 
neering manager on the engineering staff of 
RCA’s Government Systems Division, where 
he specialized in the reliability and testing of 
monolithic and hybrid ICs. He has also held 
engineering and management positions at 
Aeroneutronic-Ford; Inselek, a maker of 
silicon-on-sapphire integrated circuits; Gen¬ 
eral Electric Space Systems; and International 
Resistance Co. 

Anderson received a BSEE from Drexel 
University and an MA in business manage¬ 
ment from Central Michigan University. He 
received the US Jaycee’s Distinguished Service 
Award and was nominated an Outstanding 
Young Electrical Engineer in Eta Kappa Nu. 
He is also the recipient of numerous Com¬ 
puter Society Meritorious Service awards. 


John D. Musa 

Position statement. 
Stimulating the interna¬ 
tional processes of creat¬ 
ing knowledge and im¬ 
proving the transfer of 
knowledge to practice 
are major functions of 
the Computer Society. I 
have vigorously pursued 
these goals in the vari- 
d. I have strongly con- 
on, planning, and unit- 

depth of talents of volunteers and staff—all 
with the goal of better meeting your needs. 

As you can see from my record, I and the 
people who have worked with me have placed 
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strong emphasis on bringing you readable, 
practical, readily applicable articles in attrac¬ 
tive periodicals. 

Currently, I am leading a strong effort to 
increase the vitality and technical excellence 
of the technical committees, which are the ini¬ 
tiators in bringing you better conferences, 
technical publications, and related activities. 

I have devoted substantial effort to fostering 
and improving relationships between volun¬ 
teers and staff and encouraging entrepre¬ 
neurial attitudes. 

If elected, I will apply this philosophy, these 
policies and approaches, and the broad ex¬ 
perience I have gained to help improve the en¬ 
tire range of Computer Society service to you. 

Biography. Musa is CS second VP and VP for 
technical activities. He serves on the Opera¬ 
tions, Planning, Compensation, and Person¬ 
nel committees. He is a member of the 
editorial boards of IEEE Spectrum, IEEE 
Proceedings, and IEEE Software. 

Musa is past VP for publications. During 
his tenure, IEEE Software and IEEE Design 
& Test were launched. All the planning and 
preliminary work were completed to start 
IEEE Expert. He received the Meritorious 
Service Award for “innovative leadership in 
publications.” 

He has served on the Governing Board and 
as chairperson of the Technical Committee on 
Software Engineering. He received a Merito¬ 
rious Service Award for his leadership and in¬ 
novations in the latter position. 

As chairperson of the Steering Committee 
of the International Conferences on Soft¬ 
ware Engineering, he played a major role in 
fostering the international outlook of these 
conferences. 

Musa has been deeply involved in coopera¬ 
tive activities with ACM in software engi¬ 
neering, technical activities, and publications. 
He has participated in conferences as publici¬ 
ty chairperson, conference proceedings editor, 
technical program committee member, and 
session chairperson. He is an IEEE Senior 
Member. 

Musa is supervisor of software quality at 
AT&T Bell Laboratories. He has managed 
many different software projects. He has 
published about 40 papers in these and other 
fields, and is preparing a book, Software 
Reliability (McGraw-Hill). 


Nominees for Governing Board 
(Vote for 10) 



Tilak Agerwaia 

Position statement. One 
of the challenges that 
faces the Computer So¬ 
ciety today is to main¬ 
tain its crucial role in a 
dynamic profession. 
Major technological ad¬ 
vances continue, stimu¬ 
lated in part by the pub- 

_____ _, conferences, 

workshops, and tutorials sponsored by the 
society. However, the recent downturn in the 
industry has had an impact on the society. Af¬ 
ter a budget surplus of $1 million in 1984, the 
projected combined deficit for 1985 and 1986 
is approximately $750,000. In this rapidly 
changing environment, it is essential for the 
society to develop a long-term strategy that 
drives its shorter term decisions. I would like 
to help the society develop such a strategy so 
that it can continue to meet the needs of 
85,000 members and continue to play a 
leadership role in the field. 


Biography. Agerwaia has served as a member 
of the Fellows Committee, a member of the 


Awards Committee, a Distinguished Visitor, 
chairperson of the Eckert-Mauchly Award 
Committee, chairperson and vice chairperson 
of the Technical Committee, on Computer Ar¬ 
chitecture, and chairperson and vice chairper¬ 
son of the Central Texas Chapter. He has 
been active in the International Symposium 
on Computer Architecture since 1981, and 
served as coprogram chairperson in 1985. He 
is a member of ACM and Sigma Xi. 

Agerwaia is currently director of symbolic 
and numeric processing at the IBM Thomas 
J. Watson Research Center and is responsible 
for research programs in artificial intelligence, 
engineering/scientific computing, and parallel 
processing. 

Agerwaia received his B.Tech. in EE from 
the Indian Institute of Technology, Kanpur, 
India (1971), and his PhD in EE from the 
Johns Hopkins University (1975). 

He was elected a Fellow of the IEEE in 
1986. He received the Samuel N. Alexander 
Memorial Award from the Washington DC 
Chapter of the ACM. 


Mario R. Barbacci 

Position statement. As a 
long-term member of 
ACM and IEEE-CS, I 
would like to see closer 
ties between them (and 
perhaps a merger). The 
valuable services they 
provide could be 
streamlined and made 
more efficient by 
eliminating unnecessary duplication. Since 
many of the services provided by both 
societies result from professionals volunteer¬ 
ing their time and intellect, one must ponder 
how much better off the societies would be 
with pooled resources. 

I want to see the Computer Society con¬ 
tinue to provide a forum for the exchange of 
technical information, and I would support a 
strong program of activities in the publication 
and conference areas. 

But the Computer Society is more than a 
publishing house; it provides a focus for the 
discussion of issues of interest to computer 
professionals. I would support increasing the 
scope of the debate to include economic, 
legal, and other non-technical aspects of our 
work and their impact on the rest of society. 

Biography. Barbacci is a Senior Member of 
IEEE and IEEE-CS, member of ACM and 
Sigma Xi, and past chairperson of IFIP WG 
10.2 (Computer Descriptions and Tools). He 
has served as category editor for hardware in 
ACM Computing Reviews, and was recently 
appointed category editor for software. 

He is a member of the Software Engineer¬ 
ing Institute (SEI) Research Division and of 
the CMU CS Dept, faculty. His doctoral 
research laid the foundations for the CMU- 
Design Automation Project. Later, he de¬ 
signed and implemented the Architecture Re¬ 
search Facility, which was used in a number 
of DoD computer architecture evaluation ex¬ 
periments and led to the design and standard¬ 
ization of a military computer family. 

Prior to joining SEI, Barbacci was a mem¬ 
ber of the CMU CS Dept.’s Spice Project. He 
was a founder of SEI, responsible for the 
technical volume of the proposal that led to 
its establishment, and he has served as its as¬ 
sociate director for technology exploration. 

He is leading a joint project of the institute 
and the CMU CS Dept, that is investigating 
languages and environments for heterogene¬ 
ous computers. 

He received BSEE and Engineer degrees 
from the Universidad Nacional de Ingenieria, 
Lima, Peru, and a PhD (computer science) 
from CMU. 




Victor R. Basili 

Position statement. The 
IEEE Computer Society 
represents all activities in 
the computer science 
and engineering field. 
The society must 
(1) represent the 
members of that com¬ 
munity by supporting 
the growth and reputa¬ 
tion of their various disciplines, and 
(2) assure the advancement of the science. 
Thus, the society must actively lobby to en¬ 
sure that proper attention is focused on the 
needs and accomplishments of the field and 
its members. It is, through its journals, 
magazines and conferences, the major 
source of information to practitioners and 
researchers. 

It must continually strive to improve the 
quality and timeliness of its publications and 
meetings through better organization and 
improvement of the standards of the review 


Biography. Victor R. Basili is on the Editorial 
Board of the Transactions on Software 
Engineering and is a member of the Technical 
Committee on Software Engineering. 

He was program chairperson for the Sixth 
International Conference on Software 
Engineering and for Fall Compcon 82. He 
was chairperson of the Transactions Advisory 
Board, and a program chairperson or com¬ 
mittee member for numerous IEEE-sponsored 
conferences and workshops. 

He is a Senior Member of IEEE and ACM, 
and an associate editor for the Journal of 
Systems and Software. He has served on 
several government advisory committees and 
boards. 

He is currently professor and chairperson 
of the Computer Science Dept, at the Univer¬ 
sity of Maryland at College Park. 

Basili is the author of over 80 publications 
on software engineering and has been prin¬ 
cipal investigator for projects that represent 
over $8.5 million in government and in¬ 
dustrial grants. He has consulted for several 
companies and government agencies and has 
lectured in 10 countries. 

He holds a PhD in computer science from 
the University of Texas, an MS in mathemat¬ 
ics from Syracuse University, and a BS in 
mathematics from Fordham College. 

He won the Outstanding Paper Award 
from IEEE Transactions on Software 
Engineering in 1982 and a Meritorious Service 
Certificate from the IEEE Computer Society 
in 1985. 


P. Bruce Berra 

Position statement. We 
are in the middle of the 
information revolution. 
This revolution is so far- 
reaching that soon 
everyone on the earth 
will be affected by it. 
While these are very ex¬ 
citing times, it becomes 
more and more difficult 
to maintain technical currentness. Over the 
years the Computer Society has played an ac¬ 
tive role in keeping its members up to date on 
the latest developments and trends. However, 
we must now redouble our efforts in this 
rapidly changing world. If I am elected, I will 
continue to do everything I can to bring the 
latest information to our membership. 

In addition, because we live in a “world 
society,” I will make a special effort to pro¬ 
mote technological exchange among members 
of the computing community around the 

Thank you for your consideration. 
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Biography. Berra is currently on the Govern¬ 
ing Board, editor of the Transactions on Soft 
ware Engineering, on the Distinguished 
Visitors Program, and has just become an 
editor of the Transactions on Computers. In 
the past he has served as vice chairperson of 
the Publications Board, general chairperson 
of the Second International Conference on 
Data Engineering, the first program chairper¬ 
son of the International Conference on Data 
Engineering, chairperson of the TC on 
Database Engineering, editor-in-chief of CS 
Press, chairperson of the CS Press Advisory 
Committee, and as a Distinguished Visitor. 
He has also served on the IEEE Press 
Editorial Board and as chairperson of the 
Special Interest Group on Information 
Retrieval of the ACM. 

He is currently professor of electrical and 
computer engineering at Syracuse University, 
where he is actively involved in research on 
database and knowledge base machines. He 
has held previous academic positions at the 
University of Michigan-Dearborn, Boston 
University, and Purdue. His industrial ex¬ 
perience includes service with Hughes Air¬ 
craft, Bendix, and IBM. 

Berra, a Senior Member of the IEEE, 
received his BS degree from the University oi 
Michigan and PhD from Purdue University. 


t Wushow Chou 

Position statement. 
Among the many impor¬ 
tant services provided by 
IEEE-CS are confer¬ 
ences and publications. 
These two areas have 
served the academic 
gj community well. I 
■ would like to see them 
■ further enhanced to bet¬ 
ter serve the needs of members in the industry. 
I believe the following: 


• While the results of basic research are 
important, the results of developments 
and experiments are equally valuable. 
Both types should be equally accessible at 
conferences and in publications. 

• Conferences and publications can be bet¬ 
ter utilized for cross-fertilization between 
the research-oriented academic com¬ 
munity and the pragmatic-oriented in¬ 
dustrial community. 

• While neither IEEE nor the society seeks 
to make money from conferences, cost- 
consciousness would result in better ser¬ 
vice to members. Profit made from con¬ 
ferences or publications could be used to 
provide additional service or initiate new 


If elected, I will attempt to influence the 
Governing Board to meet these goals. I would 
also urge the Board to develop a closer rela¬ 
tionship with ACM. 


Biography. Chou is director of the Computer 
Studies Program and professor of computer 
science and electrical and computer engi¬ 
neering at North Carolina State University. 

He is also president of ACK Computer Ap¬ 
plications, Inc. 

Prior to holding these positions he was VP 
of telecommunications at Network Analysis 
Corp. (now Contel Information Systems). 

He is advisory editor for Computer Com¬ 
munications for Prentice-Hall and the series 
editor for Advances in Telecommunication 
Networks for Computer Science Press. He 
was previously the editor-in-chief of the Jour¬ 
nal of Telecommunication Networks. He has 
edited two books on computer communica¬ 
tions and has published more than 60 articles. 

Chou has served as program chairperson, 
general chairperson, and on the Steering 
Committee for the IEEE-CS Data Com¬ 
munications Symposium and as a member of 
the Technical Committee on Computer Com¬ 


munications. He also served as program area 
director in communications for the 1974 Na¬ 
tional Computer Conference. 

Among other IEEE-related activities, he 
has been general chairperson of the IEEE 
North Carolina Symposium and Exhibition, a 
member of the Executive Committee of the 
North Carolina Council of the IEEE, a guest 
associate editor, and a technical committee 
member. 

Chou, a Senior Member of the IEEE, 
received his PhD from the Dept, of EE&CS 
at the University of California at Berkeley in 
1968. 


Lorraine M. Duvall 

Position statement. One 
of the primary roles of 
a professional society is 
to transfer information 
to its members—in the 
case of IEEE-CS, with 
the goal of applying 
technology to real-world 
problems. 

The Computer Society 
fulfills this role through its many high-quality 
publications, by sponsoring conferences and 
workshops, and through its standards ac¬ 
tivities. These are all formalized mechanisms 
for the transfer of technology. More informal 
mechanisms for transferring technology are 
also effective. These include (1) direct per¬ 
sonal interface among members, which can be 
accomplished through volunteer activities in 
the technical committees and standards work¬ 
ing groups, and (2) feedback from members 
to assure better conferences and publications. 

If I am elected, I will support the devel¬ 
opment of mechanisms that will effectively 
encourage more technical interchange among 
members, nationally and internationally. 
Biography. Duvall is chairperson of the 
Technical Committee on Software Engineering 
and of the Steering Committee for the Interna¬ 
tional Conference on Software Engineering. 

She has served on the program committees of 
many IEEE conferences and workshops, and 
was the organizer and general chairperson of 
the IEEE Workshop on Total Systems 
Reliability. She was the founding president of 
the Association for Women in Computing. 

She is currently president of Duvall Com¬ 
puter Technologies, Inc., a company dedi¬ 
cated to the development and implementation 
of software technology. 

Before forming her own company, she was 
director of research for IIT Research Institute 
in Rome, N.Y., where she managed a group 
of computer scientists and engineers perform¬ 
ing research and development in software 
technology and reliability engineering. 

She designed and was the first technical 
director of the Data and Analysis Center for 
Software, an information-analysis center the 
purpose of which is to serve as a central 
source of information and data on software 
technology. 

Her prior employers include General Elec¬ 
tric and Computer Usage Co. 

Duvall received a BS in mathematics from 
Grove City College in 1960 and an MS in 
industrial engineering and operations research 
from Syracuse University in 1976. 


Michael Evangelist 

Position statement. The 
Computer Society exists 
to provide service to the 
computer science and 
engineering community. 
To my mind, the service 
of greatest importance is 
the enhancement of pro¬ 
fessional growth. I plan 
to emphasize this service 

in several ways: 




(1) On the Publications Board I have 
worked hard to increase the quality of our 
publications. The current financial crisis 
demands curtailed growth. Thus, a small 
number of high-quality, relevant magazines 
and transactions is a goal that I will continue 

(2) I will use my program committee ex¬ 
perience to help increase the quality of our 
conferences. In particular, I will support con¬ 
ferences that promote interaction between the 
academic and industrial communities. 

(3) We must offer up-to-date tutorials of 
various lengths, for many different audiences. 
The topics must be timely. I will work to 
strengthen our tutorials by analyzing sources 
of information on membership needs. 

Biography. Evangelist is currently chairperson 
of the Publications Planning Committee, a 
member of the Publications Board and the 
Editorial Board of IEEE Software, and a 
Computer Society Distinguished Visitor. 

He has been on the program committees of 
numerous conferences. Previously, he served 
on the IEEE Standards Working Groups for 
Software Productivity Metrics and Software 
Quality Metrics. As a member of the Publica¬ 
tions Planning Committee last year. Evan¬ 
gelist helped launch the new magazine IEEE 

He is a senior member of the technical staff 
in the Software Technology Program at 
MCC, where he is working on a language for 
specifying the design of distributed systems. 

Prior to joining MCC last year, Evangelist 
did research in software engineering at Bell 
Labs. He also spent four years as an assistant 
professor of computer science at Colgate 
University. 

Evangelist received his undergraduate 
degree from Beloit College, and his MS and 
PhD in computer science from Northwestern 
University. He is a member of the ACM and 
Phi Beta Kappa, in addition to the Computer 
Society. 


Wolfgang K. Giloi 

Position statement. 

I began my professional 
career in the computer 
industry, and after 20 
years of teaching in be¬ 
tween, ended up again 
directing industrial R&D 
projects. During my 
tenure as professor, 

I taught for about as 
many years in the United States as in Ger¬ 
many. Consequently, as a governor of IEEE- 
CS, I would feel well prepared for represent¬ 
ing the views and needs of CS members who 
work in the industry or in academia on either 
side of the Atlantic Ocean. 

Biography. Giloi is a long-standing member 
of IEEE-CS. He has served on the Board of 
Governors of GI, on the boards of editors of 
several journals, and as chairperson of IFIP 
WG 10.1. At present, he holds the position of 
director of the Research Center for Innovative 
Computer Systems and Technology (FIRST), 
a governmental research laboratory in West 
Berlin. In addition, he is one of the founders 
and the executive vice president for R&D of 
International Robomation Intelligence at 
Carlsbad, Calif. 

Previously, Giloi was professor of com¬ 
puter science at the University of Minnesota 
and professor of electrical engineering and 
computer science at the Technical University 
of Berlin. He has published several books and 
numerous papers in the computer field. 

Giloi has helped to pioneer analog and 
hybrid computation, computer graphics and 
image analysis, and parallel-processing ar¬ 
chitectures. He introduced the notion of 
object-oriented computer architecture and de- 
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veloped a number of highly parallel machines 
based on that principle. 

Giloi holds a master’s degree and a PhD in 
electrical engineering, both from the Univer¬ 
sity of Stuttgart. He received the VDI Ring of 
Honor Award. 


Allen L. Hankinson 

Position statement. In¬ 
formation technology is 
rapidly becoming a 
ubiquitous component 
of products and services 
used by the general pub¬ 
lic. Problems associated 
with the accelerated use 
of this technology have 
resulted in increased 
concern about issues such as public health 
and safety, consumer protection, and vendor 
liability. The Computer Society is particularly 
well suited to deal with these complex issues. 
Although the Computer Society is primarily a 
technical organization, we have demonstrated 
that we can contribute to the solution of 
problems that transcend technology. As a 
member of the Governing Board, I would 
promote activities that would contribute to 
the solution of such problems. 

Biography. Hankinson is chief of the Systems 
and Software Technology Division, Institute 
for Computer Sciences and Technology, Na¬ 
tional Bureau of Standards. He is responsible 
for research in the areas of office systems en¬ 
gineering, software engineering, and com¬ 
puter security management and evaluation. 

Hankinson is a member of the Computer 
Society’s Standards Coordinating Committee 
and Standards Activities Board, and repre¬ 
sents the Computer Society as a member of 
IEEE’s IntCom and NesCom. He has been an 
active participant on planning committees for 
Computer Society conferences and symposia. 

He received a BS in mathematics, Florida 
A&M University, in 1962 and a master’s in 
computer science, University of Virginia, in 
1968. 



William Howden 

Position statement. My 
primary concern is that 
the activities of the CS 
be motivated by funda¬ 
mentals: engineering, 
technology, and scien¬ 
tific research. Confer¬ 
ences and publications 
must not become ends in 
themselves. The CS has 
created new conferences and publications to 
help members keep abreast of a rapidly 
changing field. It must continue to do this in 
a responsible way: introducing new activities 
in response to change and withdrawing from 
activities that no longer serve their original 
purpose. 

I agreed to run for the Board of Governors 
because I think the CS is one of the most im¬ 
portant computer science organizations in the 
profession. I have no personal interest in oc¬ 
cupying a position of organizational authori¬ 
ty. I am motivated by a sense of professional 
responsibility and a desire to help the CS 
maintain its leadership role. 

Biography. I have been involved in research 
and advanced development in software engi¬ 
neering for approximately 15 years. Most of 
the research has been in software testing. I 
have participated in the development of 
several testing and analysis tools, and have 
worked in design and specifications. 

My past CS involvement has been with con¬ 
ferences and publications. I was on the pro- 
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gram committees for the fourth through the 
ninth International Conference on Software 
Engineering and was a program chairperson 
for the seventh conference. 

I am on the Editorial Board of IEEE 
Transactions on Software Engineering. I am a 
member of 1FIP WG 10.4, Fault-Tolerant 
Computing. I am a full professor of computer 
science at the University of California at San 
Diego, where 1 have been a faculty member 
since 1974. I have also been an applications 
and a systems programmer. 

My current research project is on testing 
and analysis for real-time systems. It is based 
on a book I have written called Functional 
Testing and Analysis, which will be published 
by McGraw-Hill later this year. 

I have a PhD in computer science from the 
University of California at Irvine and MSc 
degrees in CS and mathematics. 

I have been a CS Distinguished Visitor for 
several years. 



Barry Johnson 

Position statement. A 
fundamental goal of the 
Computer Society is 
promoting the exchange 
of technical information 
among members. This is 
■ accomplished through 
I technical publications, 

I conferences, and educa- 
I tional programs. To re¬ 
main a premier organization, we must main¬ 
tain technical quality and financial vitality in 
each of these areas. 

I feel that a key element in maintaining 
quality is increasing cooperation between our 
members in academia and our members in in¬ 
dustry. We need more joint participation by 
them in the selection and preparation of time¬ 
ly conferences, tutorials, articles, and text¬ 
books in key technology areas. 

We must also ensure that our programs are 
fiscally sound. Membership fees pay only a 
small portion of the cost of the technical ser¬ 
vices provided by the society. As a result, we 
must generate revenue in areas such as con¬ 
ferences and publications so that we can sup¬ 
port other critical activities that are incapable 
of producing revenue. 

If elected, I will strive to meet these 
objectives. 


Biography. Johnson is presently active in the 
Computer Society as a member of the 
Editorial Board of IEEE Micro, as finance 
chairperson of the Conferences and Tutorials 
Board, and as a member of the Finance Com¬ 
mittee. He has been an active participant in 
IEEE conferences as both an author and a 
session chairperson. 

Johnson is currently an assistant professor 
in the Dept, of Electrical Engineering at the 
University of Virginia and is a member of the 
Center for Semicustom Integrated Systems, a 
research center within the university’s School 
of Engineering and Applied Science. 

Prior to joining the university, he was with 
Harris Corp. in Melbourne, Fla., where he 
participated in the design and analysis of 
fault-tolerant aerospace systems. 

His research interests include fault-tolerant 
computing, VLSI architectures, VLSI testing, 
and microcomputer control. He has published 
approximately 25 papers in the above fields 
and is currently preparing a text on fault- 
tolerant computing. 

Johnson received the BS, ME, and PhD 
degrees in electrical engineering from the 
University of Virginia, Charlottesville, Vir¬ 
ginia, in 1979, 1980, and 1983, respectively. 

He is a member of the IEEE, the Computer 
Society, Tau Beta Pi, Eta Kappa Nu, and 
Sigma Xi. 


Laurel Kaleda 

Position statement. I be¬ 
lieve that the Computer 
Society’s history of sus¬ 
tained growth is due in 
part to strong leadership 
in our field and a solid 
blending of theory and 
practice in all activities. 

The size, complexity, 
and diversity of the 
society require that its Governing Board and 
officers ensure efficient, effective society 
operations while encouraging continued ex¬ 
pansion and enhancement of services to 
members. This challenge is compounded by 
the rapid advancement of computer technolo¬ 
gy, the growing demand for urgently needed 
national and international standards, and the 
current economic climate. 

Managing a professional association of this 
size requires considerable time, energy, and 
commitment to the goals of the organization. 
The previous and current governing boards 
have made substantial improvements in the 
operations of the society so that growth in 
membership levels and services can be sup¬ 
ported effectively. They have done this with a 
strong sense of fiscal responsibility. 

If elected, I will work to continue this pro¬ 
gress. 

Biography. Kaleda is division standards 
authority for IBM’s General Products Divi¬ 
sion in San Jose, Calif. The division produces 
disk and tape drives and controllers, as well as 
major software products. 

Kaleda was previously manager of pro¬ 
gramming languages assurance for IBM 
GPD. Her 18 years with IBM have provided 
her with a wide range of experience, both 
with computers of various sizes and with a 
variety of software. 

She is chairperson of the IEEE Standards 
Coordinating Committee, and a member of 
the Standards Activities Board (SAB), the 
Software Engineering Standards Subcommit¬ 
tee (SESS), and the Microprocessor Standards 
Committee. She was treasurer of the SAB 
(1984-85), a member of the Finance Commit¬ 
tee (1984-85), and secretary of the SESS 
(1982-85). She organized and chaired a panel 
session of Software Engineering Standards at 
NCC-85 and was a member of the Program 
Committee for the Software Engineering 
Standards Application Workshop III. 

Kaleda has a BS in applied math and com¬ 
puter science from Washington University, St. 
Louis, and an MBA from Golden Gate 
University, San Francisco. She is a Licensed 
Professional Engineer in California, a 
member of IEEE and ACM, and participates 
in the Software Reliability Subsection of the 
Santa Clara Valley Section of the American 
Society for Quality Control. 



Ted Lewis 

Position statement. The 
Computer Society has 
been very successful in 
the past because of its 
responsiveness to the 
needs and desires of its 
members. We must con¬ 
tinue to provide timely, 
accurate, and useful in¬ 
formation to our mem¬ 
bers through support of professional activi¬ 
ties, publications, and tutorials. 

I am especially interested in continued im¬ 
provement in our publications (for example, 
Computer, Software, Expert, and the various 
tutorial books). As a past coeditor of Com¬ 
puter and a current member of the Editorial 
Board of Software, I have participated in the 
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transition of these publications from limited 
to widespread readership. 

Computer Society publications have 
become widely referenced in other journals. 
We now need to find ways to make these 
publications available to a broader group of 
practitioners. We must enable students, engi¬ 
neers in other disciplines, scientists, and 
educators to access these publications to fur¬ 
ther the use of computing in their respective 
occupations. 

Biography. Ted Lewis is a member of the 
Editorial Board of and the software reviews 
editor for IEEE Software magazine. He was 
previously a coeditor-in-chief of Computer, 
for which service he received the IEEE Com¬ 
puter Society Honor Roll award in 1982. 

Currently, Lewis is professor of computer 
science at Oregon State University. 

He is the coinventor of the Tausworthe- 
Lewis-Payne algorithm (used extensively in 
cryptography) and is the developer of the first 
retargetable microprogramming language sys¬ 
tem for implementing efficient microprograms. 

Lewis has published extensively in the areas 
of software engineering, distributed operating 
systems, and computer organization and ar¬ 
chitecture; he has authored a number of 
books on personal computers, software engi¬ 
neering, and Pascal. 

Lewis received the BS degree in mathemat¬ 
ics from Oregon State University in 1966, and 
MS and PhD degrees from Washington State 
University in 1970 and 1971, respectively. 

He has been on the faculty of the depart¬ 
ments of computer science at the University 
of Southwestern Louisiana (1973-76), and the 
University of Missouri-Rolla (1971-73). 


Ming T. (Mike) Liu 

Position statement. A 
challenge facing the 
computer professional is 
how to keep pace with 
rapidly advancing 
technologies such as 
VLSI, AI, supercom¬ 
puting, and networking. 
The main purpose of the 
Computer Society is to 
provide technical programs and professional 
services to enable its members to keep abreast 
of evolving technological changes. It serves its 
members through publications, conferences 
and tutorials, chapter and educational ac¬ 
tivities, and technical and standards activities. 
All of these functions must remain active, 
strong, flexible, and innovative so as to 
maintain the technical vitality and leadership 
of its members. 

In the past, I strongly supported and active¬ 
ly participated in these activities. If elected, I 
will continue to support these activities and to 
seek innovative ways to help our members 
successfully meet their professional 
challenges. 



Biography. Liu currently serves as vice presi¬ 
dent for membership and information ac¬ 
tivities and as a member of the Governing 
Board. He also serves as editor-in-chief of 
IEEE Transactions on Computers and as a 
member of the ACM-CS Eckert-Mauchly 
Award Committee and the IEEE Fellows 
Committee. 

Liu is a past chairperson of the IEEE 
Technical Committee on Distributed Process¬ 
ing, which grew to a membership of 1500 
from 300 during his term. He served as pro¬ 
gram chairperson and general chairperson of 
the International Conference on Distributed 
Computing Systems in 1985 and 1986, respec¬ 
tively. In 1985 he chaired the CS Tutorials 
Committee and expanded its tutorial week 
program from two to eight. He received a 
Meritorious Service Award “for contributions 


to the Technical Committee on Distributed 
Processing and to the IEEE Computer Socie¬ 
ty’s tutorials and conferences.” 

A professor of computer and information 
science at Ohio State University, he has 
published 90 technical papers and supervised 
30 doctoral dissertations. In 1983 he was 
elected an IEEE Fellow “for contributions to 
distributed processing, computer networking, 
and education in computer science.” 

Liu holds MSEE and PhD degrees from the 
University of Pennsylvania. In 1983-84 he 
spent his sabbatical leave at AT&T Bell Labs, 
working on automated validation of com¬ 
puter-communication protocols. 


H. Troy Nagle, Jr. 

Position statement. The 
Computer Society is 
unique: It resides within 
IEEE, yet has an in¬ 
dependent staff and of¬ 
fice buildings. With an 
annual budget of over 
$14,000,000, the volun¬ 
teer leaders and staff 
directors spend most of 
their time worrying about budgetary issues. 
Membership services tend to receive less atten¬ 
tion than they deserve. As a Governing Board 
member, I would work to change this situa¬ 
tion by 

(1) adopting a long-range budget plan that 
calls for constant funding levels for all CS 
programs (no spending sprees in good 
times or drastic budget cutting in bad), 

(2) reducing the number of Executive Com¬ 
mittee and Governing Board administra¬ 
tive meetings, 

(3) improving the efficiency of CS opera- 

(4) improving the quality of membership ser¬ 
vices (publications, conferences, 
workshops), and 

(5) increasing the level of support for CS 
chapters (distinguished visitors, tutorials, 
chapter officer training). 

The CS is the premier organization of its kind 
in the world. I will strive to keep it strong and 
vital. 

Biography. Nagle is professor of ECE at 
North Carolina State University and consul¬ 
tant to Motorola Government Electronics 
Group in Phoenix, Ariz. 

He is widely published in data acquisition 
and control systems and is coauthor of text¬ 
books on digital logic design and sampled- 
data-control systems. His current research 
areas are computer architecture and fault- 
tolerant systems design. 

He received the BSEE and MSEE from the 
University of Alabama, and the PhD degree 
in EE from Auburn. He received the MD 
degree from the University of Miami Medical 
School, and plans to focus his future research 
on reliable microelectronics for human 
implantation. 

Nagle belongs to Phi Kappa Phi, Tau Beta 
Pi, Eta Kappa Nu, Sigma Xi, and Omicron 
Delta Kappa. He is in Who’s Who in 
America ; he received the IEEE Centennial 
Medal. 

Computer Society: VP for area activities. 
Chapter Development Committee chairper¬ 
son. Data Acquisition and Control Commit¬ 
tee chairperson. Distinguished Visitors Pro¬ 
gram. Finance Committee. Magazine Advi¬ 
sory Committee. Press Advisory Committee. 
Alabama Computer Society Chapter 
chairperson. International Conference on 
Distributed Computing Systems (Steering 
Committee). Medcomp 82 (Program Com¬ 
mittee). Real-Time Systems Symposium 
(Steering Committee). Compsac 78 (Pro¬ 
gram Committee). 



IEEE committee/board activities (S’66, 
M’70, SM’74, F’83): Technical Activities 
Board, TAB Committee on Man and Radia¬ 
tion, TAB Finance, TAB Meetings, Student 
Activities. 


Raymon Oberly 

I Position statement. The 
I Computer Society is a 

I very dynamic organiza- 

a . tion that is willing to 

—take the risk of explor- 
ing new ways of serving 
y its members. Some ex¬ 
it amples of services 

conferences, workshops, 
tutorials, and technical 
magazines (e.g., IEEE Design <£ Test); these 
provide a way for the professional to keep 
abreast of the latest technical information in 
his or her field. 

As a Governing Board member, I would 
continue my policy of looking for ways to 
bring the latest technical information to the 
professional. I would propose having tutorials 
given in areas where the members work so 
that they could save travel time and costs. I 
would also propose encouraging more 
workshops in locations outside the United 
States to provide greater opportunity for 
technical exchange to non-US members at less 
cost to them. These additional workshops 
would truly make the Computer Society an 
international organization. 

I will continue my efforts to increase 
membership and technical-magazine subscrip- 


Biography. Oberly, an IEEE Senior Member, 
currently participates in these Computer 
Society activities: East Coast Operations 
Committee, Conference and Tutorials Board, 
Membership Committee. He is Division VIII 
representative to the IEEE TAB Meetings 
Committee. He is a member of the Test 
Technology Technical Committee and was its 
vice chairperson and chairperson. 

He has been on the Program and Steering 
committees for the International Test Con¬ 
ference since 1977, and has also served as pro¬ 
gram chairperson and treasurer. He has de¬ 
voted three years to helping IEEE Design & 
Test magazine become successful. 

Oberly is a senior engineer at IBM and pro¬ 
vides technical-staff support to the program 
office responsible for developing large com¬ 
puters. Each year he also runs two internal 
IBM conferences devoted to electrical testing 
from components to field. In the past, his 
responsibilities included development and im¬ 
plementation of component- and board¬ 
testing methodologies, development of 
various test and cost trade-off analyses, and 
performing qualification and reliability testing 
of semiconductor components. 

Oberly has a BA in physics from Lehigh 
University and an MS in operations research 
from Union College. He has published and 
presented 12 papers on testing and has par¬ 
ticipated on numerous conference and work¬ 
shop committees. 

He received the Computer Society 
Meritorious Service Award in 1985. 


Gordon C. Padwick 

| Position statement. The 
I Computer Society is an 
I organization that has ex- 
1 citing potential, but 
| lacks a clearly defined 
s mission. As your repre- 
sentative on the Govern- 
ing Board, my aim 
fi f would be to help define 

t t the society’s mission 

as a result, make the society more effec- 
in promoting the interests of all computer 



September 1986 


93 















professionals and bringing the benefits of 
computers to society at large. 

I would endeavor to encourage the society 
to become a leader in the use of computer- 
based tools for the benefit of members, par¬ 
ticularly in the areas of education and com¬ 
munication. I would strive to increase the use 
of electronic methods of communication to 
make conferences, seminars, workshops, and 
business meetings more readily accessible to 
members. 

A third important objective would be to in¬ 
crease society membership by spreading infor¬ 
mation about the society among the many 
computer professionals who are not members 
at present. 

I ask for your support and, if elected, will 
conscientiously represent your interests. 

Biography. Gordon Padwick has been a 
member of the IEEE for 25 years and a 
Senior Member since 1963. He has served on 
the Program Committee of the International 
Test Conference, sponsored by the Computer 
Society, for five years and is program chair¬ 
person for the 1987 conference. Padwick was 
a founding editor of IEEE Design & Test 
magazine, and still serves on the magazine’s 
Editorial Board. He is currently a member of 
the Computer Society Planning Committee, 
the West Coast Operations Committee, and 
the Computer Services Advisory Committee. 
He previously served on the Conferences and 
Tutorials Board and on the Membership 
Committee. He was guest editor of the April 
1986 Design Automation Special Issue of 
Computer magazine. 

Padwick has written extensively, particular¬ 
ly in the areas of semiconductor devices and 
automatic test equipment. He recently con¬ 
tributed a chapter on automatic test equip¬ 
ment to the Handbook of Computers and 
Computing, published by Van Nostrand. 

Padwick has been employed by Teradyne, 
Inc. for over 17 years and has held manage¬ 
ment positions in engineering, marketing, and 
communications. Previous employers include 
Fairchild, SGS, General Electric, IBM, and 
Philips. He has taught various electronics 

He was educated in England and graduated 
from Queen Mary College, University of 
London, in 1957. 


Roland J. Saam 

Position statement. I 
will work for three 
objectives: 

• Transnational 
vitality. IEEE-CS is 
unique in its outlook; it 
draws members from 
dozens of countries. We 
all share the excitement 
and love of advancing 
knowledge. Keeping the leading edge world¬ 
wide means greater challenges for and 
benefits to us, and requires cooperation with 
kindred societies worldwide. 

• Cost-effective communication. Our 
publications retain their high quality and 
pragmatic and theoretical balance, but new 
programs must be devised that attract new 
members. Development of low-cost, low- 
financial-risk tutorials/mini-work¬ 
shops/seminars is essential to maintaining the 
society’s fiscal health and active membership 
participation. 

• Increasing membership. Today’s focus of 
attention is the computer. An enormous po¬ 
tential exists for orderly association growth, 
which will enlarge our influence and bring 
about a richer Computer Society. Combining 
our engineering strengths with strengths of 
other disciplines is, in my opinion, the way to 
build membership effectively. I believe that 
Industry should be given more incentives to 
support the Computer Society. 



Biography. Saam has served the Computer 
Society as chairperson of European Advisory 
Committee, in which capacity he was respon¬ 
sible for guiding the operations of the CS 
European Office in Brussels and informing 
the Governing Board of activities and oppor¬ 
tunities in the area. He started the United 
Kingdom and Republic of Ireland Chapter of 
the CS in 1981, and promoted area activities 
with mini-workshops and other events. 

Saam is president of Micros For Managers, 
a London company specializing in portable 
personal computers and engineering software. 
He pioneered the concept of offering low-cost 
professional applications with the computer 
given “free.” 

A New York City native, Saam has the 
BEE from Manhattan College and the MS in 
industrial and management engineering from 
Columbia University. After learning computer 
applications programming and systems devel¬ 
opment at IBM, he was assigned to London 
in 1968, where he stayed. 

Having a passionate interest in interna¬ 
tional business and management, Saam 
worked for Peat Marwick Mitchell Manage¬ 
ment Consulting Firm, Sperry Rand Europe, 
and Gulf Oil Co. He is Fellow of the Institute 
of Cost and Management Accountants. 

He swims and sails off the south coast of 
England. At times he can be seen talking to, 
operating, or solving problems with a pocket 
computer. 


Earl E. Swartzlander, Jr. 

Position statement. Over 
the last two decades, I 
have performed a wide 
range of volunteer roles 
in the IEEE-CS. I hope 
to continue my involve¬ 
ment as a Board of 
Governors member. 

Our society faces a 
severe financial chal¬ 
lenge. We need to provide more and better 
services to the membership in a severely cost- 
constrained environment. Conferences and 
tutorials represent the forefront of the 
challenge. 

Declining attendance (in part because of 
current cost constraints in industry) has 
forced curtailment of the tutorial program. 

Conferences are feeling the crunch as well. 
Better coordination between conference plan¬ 
ners and the Technical Activities Board should 
help ameliorate the problem. We also need to 
coordinate and manage the budgets of major 
conferences carefully. 

I also want to encourage grouping of 
workshops and symposia so that attendees 
who travel to one can easily attend a second 
event without a second trip. Such “double 
headers” will simplify local coordination, 
registration, etc. 

Biography. Swartzlander is an editor of IEEE 
Transactions on Computers, an associate 
editor of IEEE Journal of Solid-State Cir¬ 
cuits, conferences chairperson of the Con¬ 
ferences and Tutorials Board, and IEEE-CS 
representative on the IEEE Solid-State Cir¬ 
cuits Council. 

He was general chairperson of three IEEE 
Real-Time Systems Symposia (1980-1982) and 
the IEEE International Conference on Dis¬ 
tributed Computing Systems (May 1985). He 
was chairperson of the IEEE-CS TC on Real- 
Time Systems (1982-1983). 

He is a member of the Journal of Parallel 
and Distributed Computing Editorial Board 
and is hardware area editor for ACM Com¬ 
puting Reviews. 

Swartzlander manages the TRW Electronic 
Systems Group’s Digital Processing Labora¬ 
tory. Recently, he conceived and managed the 
development of the first semicustom IC with 
over 100,000 transistors. 



Prior to joining TRW, he designed and 
tested the electronic system of a solar spectro- 
heliometer used on Skylab. 

BSEE: Purdue. 

MSEE: University of Colorado. 

PhD (computer design): University of 
Southern California. 

Swartzlander has written the book VLSI 
Signal Processing Systems and over 50 papers 
on computer architecture, VLSI implementa¬ 
tion, and computer arithmetic. He edited the 
books Computer Design Development and 
Computer Arithmetic, is a Senior Member of 
IEEE; belongs to Eta Kappa Nu, Sigma Tau, 
and Omicron Delta Kappa; and is a Regis¬ 
tered Professional Engineer in Alabama, 
California, and Colorado. 


Joseph Urban 

Position statement. The 
Computer Society has 
been impacted by the 
current state of the com¬ 
puter field. This situa¬ 
tion has resulted in our 
taking cost-saving 
measures even as we 
strive to maintain quali¬ 
ty publications and 
technical activities. Publications, tutorials, 
and conferences must meet the needs of the 
membership, yet be economical. 

We need to have, as a response to this 
effort, improved feedback from members on 
services provided by the society. The Com¬ 
puter Society must continue to maintain a 
professional-leadership role. Its products 
must be easily attainable by the members. 

I will continue to support non-US-based 
technical activities, such as conferences, lec¬ 
tures by visiting speakers, and networks. 

I will work to achieve a sound technical and 
financial position for the Computer Society. 

Based on my past experience with the Ex¬ 
ecutive Committee and the Technical Ac¬ 
tivities, Publications, Conferences and 
Tutorials, and Area Activities boards, I 
believe that I can continue to serve the society 
in a positive manner. 

Biography. Urban is an editor of the IEEE 
Transactions on Software Engineering and 
IEEE Expert, a member of the Board of 
Governors and Executive Committee, trea¬ 
surer, and Finance Committee chairperson. 

He is conference chairperson of the 1986 
International Conference on Computer 
Languages. He initiated and was chairperson 
of the Computer Languages Technical Com¬ 
mittee and was chairperson of the Publica¬ 
tions Planning Committee. He was chairper¬ 
son of and has lectured in the Chapter 
Tutorials and in the Distinguished Visitors 
programs. He was conference chairperson of 
the 1984 Ada Applications and Environments 
Conference and 1984 International Sym¬ 
posium on Logic Programming. 

He is an associate professor of computer 
science, with responsibility for the software 
engineering program at the University of 
Southwestern Louisiana. 

He worked at the US Army Signal Center 
and the University of South Carolina, 
Columbia. 

His research areas are in software engi¬ 
neering and computer languages. 

Urban earned a BS in computer science 
from Florida Institute of Technology (1973), 
an MS in computer science from the Universi¬ 
ty of Iowa (1975), and a PhD in computer 
science from the University of Southwestern 
Louisiana (1977). 

His PhD thesis was selected by the ACM 
Doctoral Forum as one of the four best com¬ 
puter science theses produced in 1977-1978. 
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CALL FOR PAPERS 


1987 INTERNATIONAL SYMPOSIUM ON MULTIPLE-VALUED LOGIC 


UNIVERSITY OF MASSACHUSETTS AT BOSTON 
BOSTON, MASSACHUSETTS, USA 
May 26-28, 1987 

The Multiple-Valued Logic Technical Committee of the IEEE Computer Society will hold its 
17th annual symposium on May 26-28,1987 in Boston, Massachusetts, USA. The 
symposium is sponsored by the IEEE Computer Society, the University of Massachusetts at 
Boston and by Digital Equipment Corporation. You are invited to submit an original 
research, survey, or tutorial paper on any subject in the area of Multiple-Valued Logic, 
including but not exclusively limited to: 


ALGEBRAIC AND FORMAL ASPECTS 
CIRCUIT/DEVICE IMPLEMENTATION 
FAULT DETECTION AND DIAGNOSIS 
LOGIC DESIGN AND SWITCHING THEORY 
PROBABLISTIC AND 
VARIABLE-VALUED SYSTEMS 
HIGH SPEED COMPUTATION 


OPTICAL COMPUTING 
RELIABILITY 
FUZZY LOGIC 
PHILOSOPHICAL ASPECTS 
AUTOMATED REASONING 
COMPUTER SECURITY 
LOGIC PROGRAMMING 


Authors should submit four copies of each paper, typed doubled spaced on 8.5 by 11 inch or 
A4 paper by November 1, 1986. Each paper should be no longer than 20 pages and should 
include a 50-100 word abstract. Authors will be notified by February 1, 1987. Photo-ready 
copies of accepted papers are due by March 1, 1987. Papers should be sent to: 


Americas 


Europe/Africa 


Asia/Pacific 


Prof. Ivo Rosenberg 


Prof. H.G. Kerkhoff 


Prof. Okihiko Ishizuka 


Research Center for Applied 
Mathematics University of 
Montreal, Montreal, Quebec 
Canada CP 6128, Succ. A 
H3C 3J7 

For additional informatic 


Twente University of 
Technology, Department 
Electrical Engineering 
IC-Technology & Electronics 
Group, 7500 AE Enschede, 
The Netherlands 
contact: 

Prof. Dan Simovici 


Symposium Chair, ISMVL87 
Department of Mathematics 
and Computer Science, 
University of Massachusetts at 
Boston, Boston, MA 02125, 
USA (617) 929-7966 


Department of Electrical 
Engineering, Miyazaki 
University, 1-1-1 Kirishima, 
Miyazaki-shi 880 Japan 



IEEE COMPUTER 
SOCIETY 


UNIVERSITY OF 
MASSACHUSETTS/Boston 


SD1DD1D 


DIGITAL EQUIPMENT 
CORPORATION 



MVL TECHNICAL 
COMMITTEE 




















NEW PRODUCTS 


Editor: Demetrios Michalopoulos/California State University, Fullerton 


Zoran offers systems processors for DSP 


Zoran Corp. has announced two families 
of digital signal processing semiconductors, 
one including a monolithic vector processor 
called the Vector Signal Processor, or VSP 
(ZR34161), and the other, four- and eight- 
stage digital filter processors, or DFPs 
(ZR33481-20 and ZR33881-20). The ZR3881 
is reputedly capable of processing up to 340 
million operations per second. 

The VSP performs fast Fourier transforms, 
correlations, sine/cosine transforms, spec¬ 
trum analyses, and digital filtering. According 
to the company, it also features 16-bit com¬ 
plex, block floating-point arithmetic; 128 
complex point FFT in less than 250 ms; 1024 
complex point FFT in less than 2.5 ms; data 
manipulation and vector instructions; mul¬ 
tiple processors that can be paralleled; and 
CMOS, 48-pin DIP packaging. 

The DFPs rely on parallel processing ar¬ 
chitecture to achieve real-time image process¬ 
ing, according to the company. They support 
multiple data formats and a 20-MFlz through¬ 
put rate, plus a 26-bit accumulator. They 
come in CMOS, 68-pin LCC packaging. 

Support tools for the VSP include the VSP 
Simulator, software that runs on standard 
computers running under Unix, VMS, and 
MS-DOS. The Simulator allows simulation of 
the VSP IC, the VSP architecture and instruc¬ 
tion set, and the environment external to the 
VSP. Another tool, the Application Develop¬ 
ment Board, is hardware that occupies one 
slot in the IBM PC-AT and operates in con¬ 
junction with the Simulator. The board pro¬ 
vides real-time applications development; sup¬ 
ports VSP algorithm development, logical 


program debugging, and program timing 
analysis; and supports testing and verification 
of VSP programs. 

Support tools for the DFP Systems Proces¬ 
sors include hardware and software for prod¬ 
uct design and development. DFP Software 
runs under the Unix, VMS, and DOS operat¬ 
ing systems. The support system determines 
the filter coefficients and number of taps that 
match user-specified performance criteria and 
number of stages. 

The VSP ZR34151 costs $700 in sample 
quantities. The VSP Simulator is available 
with a variety of license fees, but the single¬ 
machine, IBM PC-AT version costs $3000 
and the VAX version costs $5000. The VSP 
Simulator is available with a site license for 
$15,000, while a corporate license costs 
$25,000. The Application Development Board 
costs $3000 and the VSP Evaluation Board, 
$1000. 

The ZR33481-20 DFP is available with four 
stages for $275 in sample quantities. The 
ZR33881-20 DFP is available with eight stages 
for $490 in sample quantities. 

The DFP support tools, including the 
board and four ZR33881-15 DFP ICs, cost 
$2935. The DFP development software costs 
$995 for the IBM PC-AT version and $1495 
for the VAX version. 

For more information, contact Zoran 
Corp., 3450 Central Expressway, Santa 
Clara, CA 95051; (408) 720-0444. 
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Modems employ T carrier modem 

satellites has 1.5 MBPS 


Fujitsu America’s Telecommunications 
Division has announced the ST1PC series sat¬ 
ellite modems for the transmission and recep¬ 
tion of digital data by satellite. The equip¬ 
ment, available in T-l, half T-l, and quarter 
T-l versions, consists of a digital signal pro¬ 
cessing QPSK modem that includes indepen¬ 
dent frequency synthesizers for the transmit 
and receive sides, a high gain forward error 
correction codec, a CCITT v.35 scrambler/ 
descramler, a doppler buffer, and a terrestrial 
interface. 

Unit price varies upon configuration, from 
$13,000 to $25,000. Contact Fujitsu America, 
Inc., 3055 Orchard Dr., San Jose, CA 
95134-2017; (408) 946-8777. 


Scitec Corp. USA has announced the 
Scitec Saturn D4 T carrier modem, reputedly 
designed to operate between NRZ data equip¬ 
ment and the North American terrestrial DS1 
services. The company claims that the modem 
features standard primary rate speeds of 1.536 
MBPS and 1.344 MBPS as well as multiples 
of 56 KBPS and 64 KBPS subrate speeds. An 
upgraded version of the Bell 306 data set, it 
provides both D4 and extended super frame 
(ESF) framing on the network side. 

The Scitec Saturn D4/ESF modem costs 
$3500. Contact Scitec Corp. USA, 850 
Aquidneck Ave., Middletown, RI 02840; 

(401) 849-4353. 


Voice controls 
PC-based workstation 

Microphonics Technology Corp. has an¬ 
nounced the VOX/COM PC, a PC-based 
voice-controlled communications worksta¬ 
tion. According to the company, the product 
is compatible with IBM PC and Hayes 
modems. It incorporates Microphonics’ Pro¬ 
nounce voice control system and the 1200-baud 
Zoom Modem XL into Microphonics’ Pacific 
Turbo XT with a 20M-byte hard disk. The 
system features a multispeed system board 
that reputedly operates at 4.77 to 14 MHz. 
Voice control permits users to create voice 
macros, invoked by voice rather than by 
keystrokes. A Touchtone decoder lets the sys¬ 
tem accept data input from any Touchtone 
telephone. The modem can be upgraded to 
2400 baud for $199. 

The VOX/COM PC costs $2495. Contact 
Microphonics Technology Corp., 25 37th St. 
N.E., Suite B, Auburn, WA 98002; (800) 
325-9206. 
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Boards use bubble 
memory 

The Bubbl-Tec division of PC/M, Inc., 
has announced the model QFI-11, a half¬ 
megabyte single-board magnetic-bubble mem¬ 
ory system for DEC LSI-11 microcomputers, 
and the PCI-1 Bubbl-Board, a bubble- 
memory board for the IBM PC, PC-XT, PC- 
AT, and compatibles. 

The QFI-11 Bubbl-Board consists of a 
4M-bit bubble device and a controller that 
emulates the DEC RX02 and RX01 floppy 
disk system. The controller handles bubble- 
device formatting and control, interfaces the 
bubble-memory system to the LSI-11 bus 
structure, and provides both soft- and hard- 
error detection and correction. The QFI-11 is 
built on a dual-height LSI-11 module and 
contains 512K bytes of storage. The QFI-11 
costs $2799 (quantity ten). 

The PCI-1 Bubbl-Board provides 512K 
bytes of storage on a standard full-size PC 
adapter card. Its circuitry handles bubble- 
device formatting and control, interfaces the 
bubble-memory system to the PC’s bus struc¬ 
ture, and provides for soft- and hard-error 
detection and correction. All optional expan¬ 
sion units can be controlled by the PCI-1, 
which operates as either a floppy disk or a 
hard disk. The 512K-byte version costs $1111 
(quantity ten). 

For more information, contact Bubbl-Tec, 
6805 Sierra Court, Dublin, CA 94568; (415) 
829-8700. 
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lO-MHz ICE for 8086,12.5-MHz ICE for 80286 


NEW LITERATURE 


Applied Microsystems Corp. has announced 
a 10-MHz in-circuit emulator for the 8086, 
Intel’s 16-bit microprocessor. The unit 
operates as a standalone or with a variety of 
host computers, including Sun, Apollo, VAX, 
IBM PCs, and compatibles. According to the 
company, it provides a real-time look at bus 
and control signals using trace modes. Trace 
memory allows capture of 2046 words of 
72-bit processor cycles. 

The 10-MHz ICE includes an event moni¬ 
tor system, which allows control of emulation 
by breaking on any combination of address, 
data, status, pass counter, and logic state 
fields. An event or combination of events, 
defined by logic statements, can be used to 


Sun Microsystems, Inc., has announced the 
Sun-3/200 Series of workstations and the 
Sun-3/110 color workstation. The new sys¬ 
tems extend the MC68020-based Sun-3 family 
of workstations. 

The Sun-3/200 workstations reputedly 
operate at 4 MIPS. The CPU features the 
25-MHz MC68020 microprocessor and 
20-MHz MC68881 floating-point coprocessor, 
with a 64K-byte virtual address memory cache 
and a high-bandwidth 64-bit processor-to- 
memory bus. Main memory is expandable 
from the standard 8M bytes to 32M bytes. A 
two-million-pixel high-resolution mono¬ 
chrome frame buffer is standard on the 
Sun-3/200 Series. The Sun-3/260HM has a 
19-inch hi-res monochrome monitor with 115 
dpi, while the Sun-3/260C color system and 
the Sun-3/260G grayscale system have 
19-inch, 1152-by-900-pixel resolution 
monitors. 

The base price of the Sun-3/260HM work¬ 
station is $33,900. Additional memory is 
available in 8M-byte increments for $12,000 
per increment. The Sun-3/260C has a base 
price of $44,900. The base price of the Sun- 
3/260G is $40,900. 


Alloy Computer Products has announced 
StarBase-III, a storage subsystem that 
reputedly allows the exchange of data be¬ 
tween the IBM PC Convertible computer and 
IBM PCs and compatibles, while also pro¬ 
viding mass storage for the IBM laptop com¬ 
puter. StarBase-III includes a 5.25-inch, 
360K-byte floppy disk drive; a 20M-byte Win¬ 
chester disk drive; a 40M-byte, 3.5-inch car¬ 
tridge tape backup unit; and a parallel printer 
port. The 5.25-inch floppy disk drive func¬ 
tions as an additional drive on the Converti- 


break emulation, trace software sequences, 
count events, or trigger outputs. 

The 10-MHz 8086 emulator costs $10,495. 

Applied Microsystems has also announced 
a 12.5-MHz ICE for the 80286, Intel’s 
16/32-bit microprocessor. The unit can 
emulate the 80286 in its protected mode. It 
has the same features listed for the 10-MHz 
ICE and costs $11,495. 

For more information, contact Applied 
Microsystems Corp., 5020 148th Ave. N.E., 
PO Box 97002, Redmond, WA 98073-9702; 
(206) 882-2000. 
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The Sun-3/110 color workstation uses a 
16.67-MHz MC68020 CPU with a 16.67-MHz 
MC68881 floating-point coprocessor to reach 
a reputed operating speed of 2 MIPS. Main 
memory is expandable from 4M bytes to 12M 
bytes. The Sun-3/110 uses eight planes of its 
ten-plane frame buffer to display 256 colors 
or gray shades selected from a palette of more 
than 16 million colors. The base price of the 
entry-level Sun-3/110LC is $15,900. The base 
price of the Sun-3/110G grayscale system is 
$15,900, while the Sun-3/110C color system is 
$19,900. 

Both series of workstations come with the 
Sun Operating System, the SunPro software 
programming environment, the SunView 
window-management and interface develop¬ 
ment system, the Sun Network File System, 
the SunCore and SunCGI graphics libraries, 
and the C, Fortran-77, and Pascal program¬ 
ming languages. 

For more information, contact Sun Micro¬ 
systems, Inc., 2550 Garcia Ave., Mountain 
View, CA 94043; (415) 960-1300. 
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ble. Users can run standard floppy disks 
directly from the Convertible or use DOS 
commands to copy files from a 5.25-inch for¬ 
mat to the Convertible’s 3.5-inch disks. 

StarBase-III has no price as yet. It will be 
available in the fourth quarter of 1986. For 
more information, contact Alloy Computer 
Products, Inc., 100 Pennsylvania Ave., Fram¬ 
ingham, MA 01701; (617) 875-6100. 
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Intellectual property rights. A 315-page report 
from the Office of Technology Assessment ex¬ 
amines the impact on the intellectual property 
system of current and future advances in 
audio and video recorders, computer pro¬ 
grams, electronic databases, telecommunica¬ 
tion networks, and other technological devel¬ 
opments. It focuses primarily on the Federal 
copyright system. Intellectual Property Rights 
in an Age of Electronics and Information, 
stock number 052-01036-4, $15. Send prepay¬ 
ment to Dept. 36-SS, Supt. of Documents, 
Washington, DC 20401; credit card orders, 
(202) 783-3238. 

Artificial Intelligence with Statistical Pattern 
Recognition (ISBN 0-13-049131-4, 372 pp., 
$49.95) by Edward A. Patrick and James M. 
Fattu maintains that it is possible to teach a 
computer to make decisions and act upon 
them. The authors show how to integrate 
methods of knowledge representation and 
rules of inference for AI with methods from 
statistical pattern recognition, including for¬ 
mal decision theory. Patrick postulates a new 
theorem of posteriori probabilities that sup¬ 
posedly supersedes Bayes Theorem, making it 
possible to work with statistically dependent 
classes. Prentice-Hall, Inc., Business and Pro¬ 
fessional Books Div., Englewood Cliffs, NJ 
07632. 

New from MIT Press. Abstraction and 
Specification in Program Development (ISBN 
12112-3, 400 pp., $39.50) by Barbara Liskov 
and John Guttag posits the value of abstrac¬ 
tion and specification as the keys to effective 
programming. The authors focus on decom¬ 
posing large program projects into indepen¬ 
dent modules. Advanced Database Tech¬ 
niques (ISBN 13215-X, 330 pp., $35) by 
Daniel Martin provides technical information 
on database methods and advanced tech¬ 
niques. It also describes the function of a 
database management system. The Art of 
Prolog: Advanced Programming Techniques 
(ISBN 19250-0, 312 pp., $29.95) by Leon 
Sterling and Ehud Shapiro explains the tech¬ 
niques and applications of Prolog and Logic 
and how to build Prolog programs. The MIT 
Press, 28 Carleton St., Cambridge, MA 
02142; (617) 253-2884. 

Optical computing. This two-volume study 
assesses the technology, business oppor¬ 
tunities, and research in the field. Diagrams 
demonstrate the basic principles discussed. It 
includes over 125 major research groups, plus 
a survey of experts in the field and their views 
on applications and market forecasts. Optical 
Computers: The Next Frontier in Computing, 
Technical Insights, Inc., Dept. OCP486, PO 
Box 1304, Fort Lee, NJ07024; $680 ($720 
outside North America). 

SCSI. The SCSI Report ($350) provides the 
basics of why and how the small computer 
systems interface is being used, an analysis of 
the total market size and structure, and a 
detailed technical discussion of the interface. 
Contact Peripheral Concepts,Inc., 18003-G2 
Skypark Circle, Irvine, CA 92714; (714) 
250-9510. 


Sun expands workstations 


StarBase-III permits data exchange between IBM 
PCs and PC Convertibles 
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Recent Microsystem Announcements 


MODEL AND RS 

FUNCTION COMPANY COMMENTS NO. 


AMT Office Plotter Advanced Matrix Technology 
Expansion card 1157 Tourmaline Dr. 

Newbury Park, CA 91320 
(805) 499-8741 


ImagEnhancer Alps America 

Controller board 3553 N. First St. 

San Jose, CA 95134 
408) 946-6000 


PC Emulator Convergent Technologies 

Module 2700 N. First St. 

Emulator San Jose, CA 95150-6685 

(408) 434-2890 


DVME-750; 
DVME-718 
LAN controller; 
SCSI controller 


DY-4 Systems 

Suite 202, 1475 S. Bascom Ave. 
Campbell, CA 95008 
(408) 377-9822 


DraftPro (HP 7570) Inquiries Manager 

Plotter Hewlett-Packard Company 

1820 Embarcadero Rd. 
Palo Alto, CA 94303 


ICE-5100/252 Intel 

Emulator Literature Dept. W-310 

3065 Bowers Ave. 

Santa Clara, CA 95052-8065 


Intelligence/ IntelligenceWare 

Compiler 9800 S. Sepulveda Blvd., Suite 730 

Compiler Los Angeles, CA 90045 

(213) 417-8896 


PSM 512DA; Plessey Microsystems 

PSM 2DA One Blue Hill Plaza 

Memory boards Pearl River, NY 10965-8541 

(914) 735-4661 


An IBM PC-XT and PC-AT expansion card that converts 70 

Houston Instrument plots for printing on the AMT Office 
Printer. Makes the AMT Office Printer compatible with soft¬ 
ware for Houston Instruments DMP-29 and DMP41 plotters. 

Cost: $595. 

An IBM PC-based controller board for hi-res graphics on 71 

Epson-compatible, nine-pin printers, monochrome or color. 

Enables a printer to accept Houston Instruments DM/PL 
plotter commands. Has a 512K-byte storage buffer. Cost: $595. 

An emulator module that lets users of Convergent’s NGEN 72 

workstations run IBM PC-compatible applications; share files 
and resources across LANs; and run MS-DOS and CTOS multi¬ 
tasking operating systems concurrently. Incorporates an Intel 
80186 microprocessor. Has 768K bytes of internal memory. 

Intended for OEMs and VARs. Cost: about $1500 for end users. 

The DVME-750 is an intelligent IEEE 802.3 Ethernet LAN 73 

controller based on the 10-MHz 68010 microprocessor. Cost: 

$2372. The DVME-718 is an intelligent small computer system in¬ 
terface controller based on an 8-MHz 68010 CPU. Cost: $1989. 

An eight-pen drafting plotter for the PC-CAD market. Com- 74 

patible with most PCs, including IBM PC, HP Vectra PC, and 
Apple Macintosh. Features pen-sorting capability. Cost: $5400. 


An emulator for the 8051 family of microcontrollers that runs 75 
on an IBM PC-XT, PC-AT or compatible running DOS 3.0 or 
later. Provides real-time debug and symbolic debug, including 
PL/M high-level language support. Cost: $6995. 

Operates on IBM PCs and compatibles. Compiles forward and 76 
backward chaining rules, inexact and semi-exact rules, frames 
and object-oriented programming, logic-based Prolog-like pro¬ 
gramming, universally and existentially quantified variables, 

Pascal procedures, and conventional programs. Includes a 
built-in b-tree system. Cost: $990. 

Multibus/iLBX-compatible memory boards with 512K bytes 77 

and 2M bytes of RAM, respectively. Maintain the IEEE 796 
form factor. On-board error detection and correction. Cost: 

$1117 for PSM 512DA, $1685 for PSM 2DA. 


LiteDrive Premier Technologies 

Internal hard disk 1890 McGaw Ave. 

Irvine, CA 92714 
(714)261-1184 


A lOM-byte internal hard disk for Zenith Data Systems’ Z-171 78 

laptop computer. Installed in place of the second floppy drive. 

Features MS-DOS compatibility and an automatic park 
function. Cost: $1295. 


SEK 9400B S-MOS Systems 

Modem evaluation 50 W. Brokaw Rd., Bldg. 7 
board San Jose, CA 95110 

(408) 993-1212 


A modem evaluation board for IBM PC-XTs and PC-ATs. 79 

Contains a 300/1200 baud modem chip set from Seiko. Epson 
compatible with Bell 212A/103A or CCITT V.22 (A, B) 
standards. Permits analog, digital, and remote digital loop back 
tests. Cost: $498. 


Concept 31 Storage Concepts 

Disk subsystem 8198-G Airport Loop Dr. 

Costa Mesa, CA 92626 
(714) 557-1862 


A disk subsystem with a 12.3M-byte/s transfer rate for real-time 80 
image processing. Contains Fujitsu’s M2360A Parallel Transfer 
Disk (PTD). Controls up to four PTDs for system storage of 
2.75G bytes. Based on a three-bus design. Cost: $48,500. 


DuraPak Sysgen 

Internal hard disk 47853 Warm Springs Blvd. 

Fremont, CA 94539 
(415) 490-6770 


An internal Winchester subsystem with removable hard disk 81 

cartridges for IBM PC, PC-XT, PC-AT, and compatibles. 

Cartridges measure 4 !4 by 4% inches and have a 15M-byte 
capacity. Cost: $1295. 
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Recent 1C Announcements 


MODEL AND RS 

FUNCTION COMPANY COMMENTS_NO. 


SLA 7000 Series S-MOS Systems 
CMOS gate arrays 50 W. Brokaw Rd., Bldg. 7 
San Jose, CA 95110 
(408) 993-1212 


TCI 10G Series 
Gate arrays 


TSG7515 
CMOS modem 


Toshiba America 
1220 Midas Way 
Sunnyvale, CA 94086 
(408) 733-3223 

Thomson Components 
1310 Electronics Dr. 
Carrollton, TX 75006 
(214) 466-6000 


A series of 1.5-micron CMOS gate arrays consisting of six gate 90 
arrays ranging from 2232 to 9250 gates with propagation delays 
of 1 ns for the internal gates. Comes in leaded and leadless chip 
carriers, DIP, surface mount, flat pack, and pin grid arrays. 

Cost: $0,003 per gate (10,000s) with engineering charges of 
$15,000 to $30,000 depending on complexity. 

Gate arrays that use the sea-of-gates/compacted arrays concept to 91 
use all area available on a silicon die. Consists of five devices with 
gate complexities ranging from 37,932 to 129,042 raw gates. 

Compatible with the TC17G and TC19G Series. Prices vary. 

A CMOS modem that meets Bell 212A, Bell 103, and CCITT 92 
V22 A-B standards. Generates and receives phase modulated 
and frequency modulated signals. Four different operating 
modes with data rates from 300 bps to 1200 bps. Cost: $53.80 
(100s). 


SSI 214; SSI 6260 
Analog processor; 
monolithic D/A 
converter 


Silicon Systems 
14351 Myford Rd. 
Tustin, CA 92680 
(714)731-7110 


The SSI 214 IC is a front-end for digital signal processor (DSP) 93 
based V.22 bis and Bell 212A compatible modems. Available in 
28-pin DIP and PLCC surface-mount for $19.95. The SSI 6260 
6-bit monolithic D/A converter IC uses an R-2R ladder 
network with precision voltage switches. TTL and CMOS com¬ 
patible. Commercial and military temperature ranges. The 
commercial version is available in 14-lead plastic DIPs for 
about $0.85 in production quantities. 



UNIVERSITY OF PETROLEUM & MINERALS 
DHAHRAN - SAUDI ARABIA 

COLLEGE OF COMPUTER SCIENCE AND ENGINEERING 
INFORMATION & COMPUTER SCIENCE DEPARTMENT 
COMPUTER ENGINEERING DEPARTMENT 


Applications for faculty positions are invited. A Ph.D or an M.S. for the lecturer positions, is 
required. Evidence of research accomplishment or potential is essential. 

Faculty will interact with undergraduate and graduate programs, and will have free access to 
extensive lab, computer and library facilities. 

The University offers attractive salary and benefits which are tax-free. 

Send resume with supporting documents to: 

UNIVERSITY OF PETROLEUM & MINERALS 
HOUSTON OFFICE, DEPARTMENT 509 
5718 WESTHEIMER, SUITE 1550 
HOUSTON, TEXAS 77057 












CAREER OPPORTUNITIES 


RATES: $4.50 per line, $45 minimum charge (up 
to ten lines). Average six typeset words per line, 
nine lines per column inch. Add $4 for box num¬ 
ber. Send copy at least six weeks prior to month 
of publication to: Carole L. Porter, Classified 
Advertising, IEEE COMPUTER Magazine, 10662 
Los Vaqueros Circle, Los Alamitos, CA 90720. 


In order to conform to the Age Discrimination 
in Employment Act and to discourage age dis¬ 
crimination, IEEE COMPUTER may reject any 
advertisement containing any of these phrases 
or similar ones: “.. .recent college grads.. 
"...1-4 years maximum experience...,” 
“... up to 5 years experience...." or “... 10 
years maximum experience.” IEEE COM¬ 
PUTER reserves the right to append to any 
advertisement, without specific notice to the 
advertiser, “Experience ranges are suggested 
minimum requirements, not maximums.” IEEE 
COMPUTER assumes that, since advertisers 
have been notified of this policy in advance, 
they agree that any experience requirements, 
whether stated as ranges or otherwise, will be 
construed by the reader as minimum require¬ 
ments only. 


SUPERCOMPUTING RESEARCH AND 
DEVELOPMENT 

The University of Illinois at Urbana-Champaign 
has established the Center for Supercomputing 
Research and Development (CSRD) with support 
from the U.S. Government, the State of Illinois, 
and industrial affiliates. The CSRD is seeking ad¬ 
ditional qualified technical staff with expertise 
in high-speed multiprocessor systems. 

The CSRD has initiated an effort to construct the 
Cedar multiprocessor that will deliver high per¬ 
formance over a wide range of computations. 
This effort is based on over 15 years of research 
in software, architecture, and algorithm develop¬ 
ment performed by a nucleus of experienced re¬ 
search staff. We are seeking additional ap¬ 
plicants with degrees in Computer Science, 
Computer Engineering or Electrical Engineering 
for the following full-time permanent positions: 

SENIOR SOFTWARE ENGINEER. To provide 
programming expertise and technical leadership 
in compiler development for parallel and array 
computers, operating systems implementation, 
and instrumentation of parallel systems for per¬ 
formance evaluation. Ph.D. preferred. M.S. 
degree with 4 years experience required. 
SOFTWARE ENGINEER. To take part in research 
and development of the above software ac¬ 
tivities. M.S. or equivalent experience preferred. 
B.S. degree with 2 years experience required. 
SENIOR COMPUTER SCIENTIST. To provide 
programming expertise and technical leadership 
in the development of multiprocessor numerical 
and nonnumerical algorithms in a variety of ap¬ 
plications, including graphics. Ph.D. preferred. 
M.S. degree with 2 years experience required. 
COMPUTER SCIENTIST. To take part in 
research and development of the above 
numerical and nonnumerical algorithms. M.S. or 
equivalent experience preferred. B.S. degree 
with 2 years experience required. 

SENIOR COMPUTER SYSTEMS ENGINEER. To 


provide expertise and technical leadership in 
development of state-of-the-art multiprocessor 
hardware. Ph.D. preferred. M.S. degree with 4 
years experience required. 

Other permanent positions in the hardware area 
may be available to take part in research and 
development of the state-of-the-art multiproces¬ 
sor hardware. At this time we believe the title will 
be Computer Systems Engineer. M.S. or equiva¬ 
lent experience preferred. B.S. degree with 2 
years experience required. In rare instances, 
equivalent qualifications will be acceptable in 
lieu of those stated above. 

We are also seeking applicants with degrees in 
Computer Science, Computer Engineering or 
Electrical Engineering for the following full-time 
and/or part-time temporary positions: 

VISITING SENIOR SOFTWARE ENGINEER. To 
provide programming expertise and technical 
leadership in compiler development for parallel 
and array computers, operating systems im¬ 
plementation, and instrumentation of parallel 
systems for performance evaluation. Ph.D. 
preferred. M.S. degree with 4 years experience 
required. 

VISITING SOFTWARE ENGINEER. To take part 
in research and development of the above soft¬ 
ware activities. M.S. or equivalent experience 
preferred. B.S. degree with 2 years experience re¬ 
quired. 

VISITING SENIOR COMPUTER SCIENTIST. To 
provide programming expertise and technical 
leadership in the development of multiprocessor 
numerical and nonnumerical algorithms in a 
variety of applications. Ph.D. preferred. MS. 
degree with 2 years experience required. 
VISITING COMPUTER SCIENTIST. To take part 
in research and development of the above 
numerical and nonnumerical algorithms. M.S. or 
equivalent experience preferred. B.S. degree 
with 2 years experience required. 

VISITING SENIOR COMPUTER SYSTEMS ENGI¬ 
NEER. To provide expertise and technical leader¬ 
ship in development of state-of-the-art multi¬ 
processor hardware. Ph.D. preferred. M.S. de¬ 
gree with 4 years experience required. 

Other temporary positions in the hardware area 
may be available to take part in research and 
development of state-of-the-art multiprocessor 
hardware. At this time we believe the title will be 
Visiting Computer Systems Engineer. M.S. or 
equivalent experience preferred. B.S. degree 
with 2 years experience required. In rare in¬ 
stances, equivalent qualifications will be accept¬ 
able in lieu of those stated above. 

Please send resume including educational back¬ 
ground, recent professional experience, and 
salary requirements to: 

Judy Maier 

Center for Supercomputing Research and 
Development 

104 S. Wright St., 305 Talbot Lab 

Urbana, Illinois 61801 

217/244-0061. 

All available positions provide salaries commen¬ 
surate with experience. 

Please specify the position or positions for 
which you are applying. If not, your application 
may be delayed. In order to insure full considera¬ 
tion, all applications should be submitted by 
September 30, 1986. Interviews may take place 
before the closing date but no final decisions 
will be made until afterthe closing date. The star¬ 
ting date is flexible. The University of Illinois is 
an Affirmative Action/Equal Opportunity 
employer. 


CASE INSTITUTE OF TECHNOLOGY 
Case Western Reserve University 

We invite applications for tenure-track positions 
at all levels. We are particularly interested in can¬ 
didates whose research areas include VLSI 
systems and design automation, applied ar¬ 
tificial intelligence, data bases, software design 
environments, and analysis of algorithms. Ap¬ 
plicants will be judged primarily on their ability 
to strengthen our quest for excellence in 
research and teaching. 

CWRU is a small private university with a total 
enrollment of about 8400, of which about 5100 
are graduate and professional students. The 
university campus is the hub of the pleasant area 
known as University Circle, an incorporation 
with neighboring cultural centers and museums. 
University Circle is about 10 miles from 
downtown Cleveland. 

Case Institute of Technology, a subunit of 
CWRU, is among the top ten engineering 
schools in terms of research funding per faculty 
member and undergraduate student quality. The 
department of Computer Engineering and 
Science has a young faculty of 10 and growing, 
and a graduate student body of 115 students, 48 
of which are currently in the PhD program. 
Department facilities includes DEC VAX-11/780, 
Data General MV/10000, twelve desk-top com¬ 
puters (Intel, DEC and Apollo), several color 
graphic displays (four high and ten medium 
resolution), and hard-copy equipment (color ink 
jet and laser printers, plotters, etc.). Faculty and 
students participating in the Center for Automa¬ 
tion and Intelligent Systems Research have ac¬ 
cess to the Center's VAX-11/782 and VAXstation 
100 display systems. Educational computing is 
provided by the Computing Center with three 
DEC-2060’s, the Case Personal Computer Lab 
with 48 DEC PRO 350's, four AT&T 3B2's and 
several AT&T 6300's, and the department’s 
MV/10000. 

Applicants should submit their resume and 
names of three references to: Professor J. 
Thomas Mortimer, Chairman; Department of 
Computer Engineering and Science; Case 
Western Reserve University, Cleveland, Ohio 
44106. 

An Equal Opportunity Affirmative Action 
Employer. 


ARTIFICIAL INTELLIGENCE 
RESEARCH POSITIONS 

Full time Research Engineer/Research Scientist 
positions are available in the Institute for Artifi¬ 
cial Intelligence in the School of Engineering & 
Applied Science on multi-year research projects. 
Research areas include: building management 
information systems, decision support systems, 
expert systems, and virtual interfaces for a vari¬ 
ety of U.S. military applications. Salary commen¬ 
surate with qualifications; Master’s degree 
desirable. 

Send resume and list of references to: 

Dr. B.G. Silverman 

Department of Engineering Administration 
School of Engineering & Applied Science 
THE GEORGE WASHINGTON UNIVERSITY 
Washington, D. C. 20052. 

We are an Equal Opportunity/Affirmative Action 
Employer. 
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HEWLETT-PACKARD 
INFORMATION TECHNOLOGY GROUP 

Hewlett-Packard has an opening for an ex¬ 
perienced individual to design and create ad¬ 
vanced training and consulting courses for 
Hewlett-Packard’s innovative new database 
management system, ALLBASE. ALLBASE is 
supported in both the commercial and the Unix 
environments and offers a choice of both rela¬ 
tional and network access to data in a single 
product. The position responsibilities also in¬ 
clude the evaluation of new database product 
functionality and supportablilty. 

Experience with the use or development of 
minicomputer or mainframe database products; 
a penchant for understanding product internals; 
and a strong interest in developing and deliver¬ 
ing training on database products is required. 
Specific knowledge of IMAGE/3000, technical 
course development expertise, and prior System 
Engineering or Technical Support experience 
are desirable. Salary is commensurate with ex¬ 
perience. Qualified candidates can call or write 
to: 

Marty Miller 

Hewlett-Packard 

Information Technology Group 

Building 47L 

19420 Homestead Road 

Cupertino, California 95014 (408) 447-5036. 


UNIVERSITY OF CALIFORNIA, BERKELEY 
Faculty Position in 
Electronics 

The Department of Electrical Engineering and 
Computer Sciences at the University of Califor¬ 
nia, Berkeley, invites applications for a tenure- 
track faculty position for teaching and research 
in electronic circuits, systems, and computer- 
aided design. Candidates for the position should 
have research experience and continuing inter¬ 
est in one or more of the following areas: 

• Microelectronics/VLSI circuit and system 
design for communications, and/or speech and 
image signal processing. 

• Computer-aided design techniques that 
span the fields of analog and digital integrated 
circuits and signal processing. 

• Computer-aided manufacturing for micro¬ 
electronics, including process modeling and 
control, computer networking, applications of 
expert systems techniques for diagnosis, 
design, and training. 

• 2-D and 3-D simulation techniques for analy¬ 
sis and design of sub-micron semiconductor 

• Microelectronic sensors, including device 
structures, fabrication methods, and associated 
circuits and signal processing techniques. 

• Heterojunction devices and circuits for 
high-speed electronics. 

Candidates should have a strong interest and ap¬ 
titude for teaching, both in their area of research 
activity and in integrated circuit design, signal 
processing, and/or computer-aided design. 

The Department prefers to make this appoint¬ 
ment at the Assistant Professor level, although 
appointment at the Associate Professor level 
with tenure may be considered for an excep¬ 
tionally well-qualified and experienced can¬ 
didate. Applicants should hold an earned doc¬ 
toral degree. Some industrial experience is 
desirable. 

Interested persons should apply by October 31, 
1986, by submitting a resume, statement of in¬ 
terests, copies of publications, and names and 
addresses of references. Apply to: 

Prof. Eugene Wong, Chairman 

Department of Electrical Engineering 
and Computer Sciences 

Cory Hall 

University of California 

Berkeley, CA 94720 


UNIVERSITY OF UTAH 
Computer Science Faculty Positions 

The Department of Computer Science at the 
University of Utah solicits applications at all pro¬ 
fessional ranks. A candidate for Assistant Pro¬ 
fessor must earn the PhD in Computer Science 
or related field prior to September. A candidate 
for Associate Professor must have, in addition, 
at least three years of teaching or research ex¬ 
perience in Computer Science. A candidate for 
the rank of Professor must have a well-estab¬ 
lished research record in Computer Science. 
The Department currently has 15 tenure-track 
faculty members, 2 teaching faculty, as well as 
an additional 11 serving in research and adjunct 
capacities. The student population includes ap¬ 
proximately 200 undergraduate majors, 40 
Master's degree students and 35 PhD students. 
Substantially funded faculty research projects 
include: asynchronous computation, computer- 
aided geometric design: computer-aided instruc¬ 
tion, computer graphics, computer system archi¬ 
tecture, computer vision, models of computation, 
program verification, programming languages, 
robotics, sensory information processing, soft¬ 
ware for small computer systems, symbolic and 
algebraic computation, theory of computation, 
and very large scale integrated circuit design. 
Funding sources include major support from the 
NSF/CER program and from DARPA. Other gov¬ 
ernmental agencies and private industry also 
provide significant support. 

Over the past few years, the department has 
created an outstanding research environment. 
The department maintains a professionally 
staffed research computing facility which in¬ 
cludes a DEC system 2060, VAX 8600, five other 
VAX mainframes and a Gould 9080. An 18-node 
BBN Butterfly parallel computer system and 
over 70 Hewlett-Packard, Apollo and Sun 
workstations are installed. The facility is con¬ 
nected to most major geographic networks (Ar¬ 
panet, CSNET, USENET and Telenet). A com¬ 
puter graphics laboratory with equipment 
representative of the most advanced devices 
available in the industry is also available. Other 
specialized laboratories include facilities for im¬ 
age processing and understanding, robotics, 
parallel processing, Lisp programming, com¬ 
puter aided instruction and VLSI research. 
Starting date for appointment is July 1987. Direct 
vita, along with the names of three or more 
references, by March 1, 1987 or until positions 
are filled, to: 

Richard F. Riesenfeld 
Recruiting Committee Chairman 
Department of Computer Science 
University of Utah 
Salt Lake City, Utah 84112 
The University of Utah is an Affirmative Action/ 
Equal Opportunity Employer and especially en¬ 
courages applications from women and 
members of minority groups. 


PURDUE UNIVERSITY 

The School of Electrical Engineering at Purdue 
University invites applications for faculty posi¬ 
tions from qualified individuals who have a 
strong commitment to teaching and research. 
Qualifications include an outstanding academic 
record, a significant involvement with a truly 
contributive research activity, and a doctorate in 
electrical or computer engineering. Areas of 
research specialization which are of particular 
interest are computers, robotics, and microelec¬ 
tronics. Resumes should be directed to: Head, 
School of Electrical Engineering, Purdue Univer¬ 
sity, West Lafayette, IN 47907. Immigration 
status of non-U.S. citizens must be stated in 
application. Purdue is an Equal Opportunity/Af¬ 
firmative Action employer. 


NORTHWESTERN UNIVERSITY 
Electrical Engineering and Computer Science 
Department Chairperson 

Applications and nominations are invited for the 
position of Chairperson of the Department of 
Electrical Engineering and Computer Science at 
Northwestern University, Evanston, Illinois. The 
department has approximately 35 full time equiv¬ 
alent faculty and operates parallel undergrad¬ 
uate and graduate programs in electrical engi¬ 
neering and computer science. 

While Northwestern has an active department in 
these two areas now, it is planning to place special 
emphasis on their expansion. The new chairper¬ 
son will have a major influence on the directions 
these plans take. Located as it is in a suburban 
environment that is part of one of the major com¬ 
mercial and industrial centers of this country, 
Northwestern presents an opportunity for making 
an existing good program outstanding. 

Interested persons are invited to send a resume 
and the names of at least three references to the 
search committee in care of: 

Prof. J. E. Van Ness 

Department of Electrical Engineering and 
Computer Science 
Northwestern University 
Evanston, IL 60201 

The search committee will welcome nomina¬ 
tions from all sources. Northwestern University 
is an affirmative action/equal opportunity 
employer. 


WORCESTER POLYTECHNIC INSTITUTE 
Head of the Computer Science Department 

Worcester Polytechnic Institute invites applica¬ 
tions and nominations for the position of Head 
of the Computer Science Department. The In¬ 
stitute seeks an individual who can provide in¬ 
novative and dynamic leadership of its educa¬ 
tional and research programs. This outstanding 
scientist and educator should have an earned 
doctorate and a distinguished record of research 
and scholarly achievement, as well as demon¬ 
strated leadership in one of the component 
specializations of Computer Science. In addition 
to administrative responsibilities, the depart¬ 
ment head will be charged with strengthening 
overall program quality and fostering scholarly 
excellence, in cooperation with other depart¬ 
ments, government and industry. 

There are 15 full time equivalent CS faculty, 260 
undergraduates, and 50 graduate students. 
Degrees are offered at the B.S., M.S., and Ph.D. 
levels. The WPI Plan, a project oriented cur¬ 
riculum, forms the basis of a unique and suc¬ 
cessful undergraduate program that has been 
accredited by the Computer Science Accredita¬ 
tion Commission of the Computing Sciences 
Accreditation Board. Department laboratories 
contain three VAX 750’s, twenty PDP 11’s, a DG 
MV/8000, and an IBM Series/1 with 35 PC’s, con¬ 
nected by Ethernets. The college is committed 
to the construction of a new Information 
Sciences building. Located near Boston, in the 
center of the computer industry, Worcester has 
eight universities and colleges, and offers a rich 
variety of professional and cultural activities. 
Nominations and applications, including cur¬ 
riculum vitae and the names of three references, 
will be accepted until December 15,1986 or until 
a suitable candidate is found. 

Please respond to: 

Professor Robert A. Peura, Chairman, Computer 
Science Search Committee, Worcester 
Polytechnic Institute, Worcester, MA 01609. An 
Equal Opportunity/Affirmative Action Employer. 


September 1986 
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UNIVERSITY OF SOUTH FLORIDA 
Computer Science and Engineering 

The Department of Computer Science and 
Engineering invites applications for faculty posi¬ 
tions at the following levels: Instructor, Assis¬ 
tant Professors, Associate Professors and Full 
Professor. The University of South Florida is the 
second largest university in Florida, with a cur¬ 
rent enrollment of over 25,000. It is located on a 
1,700 acre campus at the northeast edge of the 
sunny megatrend city of Tampa. The Tampa met¬ 
ropolitan area is one of the largest and fastest 
growing in Florida, offering a wide variety of 
cultural, entertainment, and sports activities. 
The cost of living is moderate and the quality of 
life is excellent. The area surrounding the Uni¬ 
versity is experiencing dramatic growth in indus¬ 
try and medical facilities. A variety of firms are 
located near the campus, including Honeywell, 
Sperry, IBM, GTE Data Systems, E-Systems, and 
AT&T. 

The Department of Computer Science and Engi¬ 
neering Is approximately 6 years old. It offers 
Bachelors, Masters and Ph.D. degrees in both 
Computer Science and Computer Engineering. 
The department will be housed in a new building 
in the Fall of 1986, and the size of the faculty is 
scheduled for rapid expansion over the next 
three years. A mlllion-dollar endowed chair posi¬ 
tion was recently announced. Applicants for pos¬ 
itions at all levels are especially invited in the 
areas of Computer Architecture, Distributed 
Computing/Networking, Computer Vision/ 
Graphics/Image Processing, Artificial Intelli¬ 
gence, and Software Engineering. Exceptional 
applicants in other areas are welcome. 


Applicants should send a resume and the names 
of three references to: Faculty Search Commit¬ 
tee, Computer Science and Engineering, Univer¬ 
sity of South Florida, Tampa, FL 33620. USF is an 
equal opportunity and affirmative action 
employer. 


THE UNIVERSITY OF TEXAS AT ARLINGTON 

The Department of Computer Science Engineer¬ 
ing (CSE) at The University of Texas at Arlington 
(UTA) invites your application for tenure-track or 
visiting faculty positions in all areas of computer 
science and computer engineering. Rank is 
open. An earned doctorate or equivalent and 
commitment to teaching and scholarly research 
is required. Openings are expected for January, 
June, or September 1987. Our department offers 
baccalaureate, masters, and doctoral programs. 
Excellent computing facilities are available in¬ 
cluding personal computers in each CSE faculty 
office. UTA is in the Dallas/Fort Worth metropol¬ 
itan area near a large concentration of high 
technology industries. Interested persons 
should send a resume to Professor Bill D. Car- 
roll, Professor and Chairman, Computer Science 
Engineering Department, P.O. Box 19015, The 
University of Texas at Arlington, Arlington, TX 
76019. Phone 817-273-3785. The University of 
Texas at Arlington is an Equal Opportunity Affir¬ 
mative Action Employer. 


DEVELOPMENT ENGINEER 

A young, growing, New Haven, CT area manufac¬ 
turer of scientific and engineering minisuper¬ 
computers employing a revolutionary computer 
architecture has an immediate need for two 
highly skilled Development Engineers who will 
have major responsibilities in advancing the 
Company’s proprietary compiler technologies. 
Foremost among the tasks for these positions 
are: 1) a significant contribution to the design 
and implementation of the Company’s second 
generation compiler which will greatly exceed 
the efficiency and effectiveness of its first gener¬ 
ation compiler and, 2) the evaluation and adap¬ 
tation of new developments in optimization 
research for the Company’s new compiler. Mini¬ 
mum requirements include a PhD in Computer 
Science or related relevant field, together with at 
least 2 years’ experience in the areas of compiler 
construction and optimization, in both intrapro¬ 
cedural and interprocedural data flow analysis, 
and in code generation techniques for pipelined 
scientific processors as well as experience with 
UNIX and the C programming language. Prior 
significant responsibility for the design and 
implementation of a production compiler and In¬ 
terest in user-friendly software and program¬ 
ming environments are also important. Starting 
salary is $55,000 per year for a full time position 
and includes medical, dental, and life insurance, 
two weeks annual vacation and other benefits 
competitive within the industry. Qualified ap¬ 
plicants respond with resume to: Job Service 
Technical Unit, Job Order #0390340, Connect¬ 
icut Department of Labor, 200 Folly Brook Blvd., 
Wethersfield, CT 06109. 


University of Utah 
Department of Computer Science 
Department Chairperson 

The Computer Science Department at the University of Utah 
invites applications for the tenure track position of Chairperson. 
This appointment is for a three year, renewable term. 

The Department has an internationally recognized reputation for 
excellence in research and teaching, both at the undergraduate 
and graduate levels. There are currently 15 regular faculty, and 
the full complement of faculty numbers 28. The student popu¬ 
lation of the Department comprises approximately 35 PhD 
students, 40 MS students, and 250 undergraduate majors 
selected by an annual competition among pre-majors. 

Active research areas within the Department include computer 
aided geometric design, VLSI design, information retrieval archi¬ 
tecture, parallel processing, computer simulation, robotics and 
image processing, portable Al systems sbftware, information 
based complexity theory, computer aided instruction, functional 
and logic programming, and computer music. 

The Department maintains a superb research computing facility, 
including a DECSystem 2060 and five VAX mainframes, including 
a VAX 8600. An 18-node BBN Butterfly and over seventy HP, 
Apollo, and Sun workstations are installed. Special purpose 
equipment is available for signal processing, graphics, robotics, 
and VLSI research. 

Starting date for the appointment is July 1,1987. Direct vita, along 
with the names of three references, to: 

Gary Lindstrom, Chairman 
Chairperson Search Committee 
University of Utah 
Department of Computer Science 
Salt Lake City, Utah 84112 

CONSIDERATION OF APPLICATIONS WILL CONTINUE UNTIL 1 FEBRUARY 
1987 OR UNTIL THE POSITION IS FILLED. 

THE UNIVERSITY OF UTAH IS AN AFFIRMATIVE ACTION, EQUAL OPPOR¬ 
TUNITY EMPLOYER, AND WELCOMES APPLICATIONS FROM WOMEN AND 
MINORITY CANDIDATES. 


UNIVERSITAT DORTMUND 

W/ Germany 

Department of Computer Science 

The department of computer science at the Universitat Dortmund, 
W/Germany invites applications for two full professor positions (C4 
grade according to German ranking). The department has 15 faculty 
members, over 50 persons scientific staff, 50 persons temporary 
research staff and maintains active research in theoretical computer 
science, practical computer science and selected application areas. 
The department maintains Its own computing center, a department 
computer network, has access to the university computing center and 
to all major commercial and scientific public networks. The positions 
are meant to be filled with applicants who have a special interest in 

• operating systems, micro-programming, computer architecture, 
distributed systems (Betriebssysteme, Rechnerverbund- 
systeme) 

• computer graphics, computer aided design, computer aided 
engineering (Computer Grafik, Computerunterstutzter Entwurf, 
Computerunterstiitzte Fertigung). 

The applicants are expected to have a record In research in one of the 
two areas and to take on a responsibility in undergraduate and graduate 
teaching. Applicants should be able to communicate in German. 

The position is to be filled immediately. Applications are requested to 
arrive not later than two months after the appearance of this offer. 
For more information please contact the chairman of the Computer 
Science Department: 

Prof. Dr. Joachim Biskup 
Universitat Dortmund 
Fachbereich Informatik 
Postfach 500 500 
D-4600 Dortmund 50 
West Germany 
Tel. + 49/(0)231 755 2121 
{esp311 @ unido.bitnet 














Computer Scientist. .. 

Be at the center of exciting 
scientific and engineering 
research.. .at General Electric. 

A view from 
the leading 
edge... 

GE’s Research & Development Center, one of the largest and most diversified in¬ 
dustrial laboratories in the world, has openings for experienced computer scientists/ 
software engineers in its Information Systems Operation. We are 
looking for expertise in multiprocessing, software engineering, dllf 

UNIX*, data bases, and applied mathematics. mmivi 1 

with 

extraordinary 
computer 
capability 
and support. 

Our advanced environment includes: 

■ Distributed VAXs running VMS 
and UNIX* operating systems 

■ Engineering workstations 

■ “C”, Lisp, Pascal, Ada 

■ IBM 3081 

■ LANs and Digital PBXs 


Be among 
the best in 
the field 

To qualify, you must have an MS or PhD 
in Computer Science, Engineering or 

Mathematics, backed by experience in ^ 

one or more of the following: 

■ Real-time programming/multi-processing " 3 - ~ H 

■Software engineering techniques/tools J|p|, jfcjMaL 

■ Supercomputing environments ^0 

■ Applied Mathematics T K * 

We also seek experienced personnel in Electronic Mail, UNIX* Data Bases, and 

Workstation Systems Engineering.. 

The location 
factor 

Our location in upstate New York offers a remarkable wealth of recreational, cultural 
and historical attractions, as well as some of the most relatively affordable and 
attractive housing in the country. Boston, New York and Montreal are within a few 
hours drive as are the Adirondack Mountains, Lake George and Saratoga. GE offers 
fine relocation assistance. 


Take on a Investigate excellent salaries, benefits, and growth prospects by sending your con- 

/-Viollonrto fidential resume to Mr. Neff! Dietrich, University Relations and Recruiting, Ref. 47-J, 
new Llldlieilge G enera | Electric Research & Development Center, RO. Box 8, Schenectady, 

New York 12301. Only U.S. citizens or holders of U.S. Permanent Resident visas will 
be considered. 


The future is working at General Electric. 

GENERAL ELECTRIC 


•Trademark of AT&T Bell Laboratories 


An equal opportunity employer 
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| NEXT IN COMPUTER 


October: GaAs microprocessor technology 

Because gallium arsenide transistors switch 
very rapidly, computers using GaAs inte¬ 
grated circuits will operate at considerably 
higher speeds than those using silicon-based 
ICs. DARPA’s request for a working GaAs 
microprocessor for the Strategic Defense Ini¬ 
tiative has intensified a decade of research. 
The October issue looks at the state of GaAs 
technology today. It examines the broad ar¬ 
chitectural and design issues critical to GaAs 
implementation, as well as the prototypes of 
DARPA contractors. 
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ADVANCE PROGRAM 


A symposium sponsored by 



Computer Society of the IEEE 
Technical Committee on 
Computer Communications 


computer 

networking 

symposium 


WASHINGTON, D.C. November 17-18, 1986 
Loews L'Enfant Plaza 
480 L'Enfant Plaza, S.W. 


Tutorials 


MONDAY, NOVEMBER 17, 1986 

Local Network Technology, William Stallings 

OSI and ISDN Protocols and Services, Bryan Whittle and W. Davison 


Technical Sessions 


TUESDAY, NOVEMBER 18, 1986 

• Protocol I • LAN/MAN • Performance Analysis & 

Modeling 


• Protocol II 


• Packet Switched 
Network 


• Distributed Systems/ 
Algorithms 


• Routing and Flow Control • Internetworking • Measurements 


For Further Information 


Contact: Computer Networking 

Computer Society of the IEEE 
1730 Mass. Ave. N.W. 
Washington, DC 20036-1903 
Phone: (202) 371-0101 














An Innovative Video Series 
Exploring the Frontiers 
of Technology 

M MflS tcrS 



AI MASTERS ... a unique, 
unprecedented opportunity to 
learn the techniques and applica¬ 
tions of Artificial Intelligence 
from the world's leading 
authorities. 

AI MASTERS . . . designed 
specifically for engineers and 
technical professionals, this 
comprehensive video series: 

)N- delivers state-of-the-art 

knowledge from internation¬ 
ally recognized pioneers in 
the field of AI 

^ addresses key issues through 
on-camera lectures, inter¬ 
views, case studies, and 
graphics 

^ integrates a 45-60 minute 
video tape and ten hand¬ 
books for individual or 
group study 

Machine Vision: The Advent 
f of Intelligent Robots 

Michael Brady, University of 
Oxford, England 
Examining both the cognitive 
and the engineering aspects of 
computer vision, this program 
surveys the latest developments 
in three dimensional vision sys¬ 
tems, with particular reference 
to stereo. It highlights the dif¬ 
ficulties of technology transfer 
in this area and underlines its 
necessity. Viewers will learn how 
parallel computers provide hope 
for future advances in machine 
vision. 




Logic Programming: Prolog 
and its Applications 

Bob Kowalski and Frank Kriwaczek, 
Imperial College, London 
This program illustrates logic 
programming in action through 
a demonstration of a decision 
support system for the design 
and construction of a building. 
It presents the growing range of 
applications of logic program¬ 
ming such as expert systems, 
data processing, and systems 
programming, viewers will 
investigate the future of logic 
programming and its role in 
linking AI with new computer 
architectures. 


Expert Systems: Automating 
Knowledge Acquisition 

Donald Michie, Turing Institute, 
Glasgow, and Ivan Bratko, Joseph 
Stephan Institute, Yugoslavia 
Emphasis is given to the crucial 
role of explanation facilities in 
providing a "bridge of com¬ 
prehension" between the expert 
and the user. Viewers will learn 
techniques to help avoid the 
"Feigenbaum bottleneck" in 
knowledge acquisition for expert 
systems. In-depth case studies 
of rule induction methods which 
have been proven in practice will 
provide them with a wide range 
of current and future commercial 
applications. 


Additional programs in the AI 
MASTERS Series will be avail¬ 
able in 1987. 


Soon to be released . . . additional 
video-based training programs in 
Artificial Intelligence. 
Knowledge-Based Expert Systems: 
Planning and Implementation by 
Randall Davis, MIT 
Knowledge Acquisitions: The Key 
to Building Expert Systems by 
Donald A. Waterman, Rand Corp. 
Applications of Artificial Intelli¬ 
gence by Patrick Winston, MIT 
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Canada 

Addison-Wesley (Canada) Ltd. 
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Don Mills, Ontario M3C2T8 

England 

Addison-Wesley Publishers Limited 
Finchampsteacl Road, Wokingham 
Berkshire RG112NZ 
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I.P.O. Box 5015 
Tokyo 100-31 

Netherlands 

Addison-Wesley Publishing Group 
DeLairessestraat 90 
1071 PJ Amsterdam 

Addison-Wesley (Singapore) Pte. Ltd. 
333 North Bridge Road 
07-01 Choon Bee Building 
Singapore 0718 


For further information, call or write: 

Addison-Wesley Training Systems 
Route 128 

Reading, Massachusetts 01867 
(617) 944-3700, extension 2714 

















